Crystal 1.22

原文 ↗ Hacker News 讨论 ↗

Crystal 1.22 是一门受 Ruby 启发、通过 LLVM 编译的静态类型语言，因兼具原生性能、轻量绿色线程和优雅语法而再次受到关注，但在运行时成熟度和并行优化方面仍落后于 Go。评论者强调它在 CLI 工具和后端服务中的优势，称其相较 Ruby 具有显著的速度和内存收益，同时也指出编译慢、直到最近才补齐较完整的 Windows 支持，以及行业采用度有限等缺点。讨论还反映出当下生态中的一个更广泛张力：在强大的 LLM 以及 Go、Rust、TruffleRuby 等有力替代方案存在的情况下，一些人质疑 Crystal 的细分定位和长期相关性，而另一些人仍将其视为一种优雅、务实的选择。

定位与目标

  • 常被描述为“带有 Go 式并发的类型化 Ruby”或“语法像 Ruby 的 C”。
  • 目标是将 Ruby 的易用性和面向对象特性与原生性能、静态类型以及易于分发的二进制文件结合起来。
  • 有些人觉得它与 Ruby 太相似，难以形成自己的细分领域，但又与 Ruby 相差太远，无法充分受益于 Ruby 的生态系统。

并发与性能

  • 早先的批评是：尽管并发能力不错，Crystal 在并行性上仍落后于 Go。
  • 近期版本引入了“Execution Contexts”作为并行引擎，据称比 Go 的运行时更可调，但在优化和线程安全库方面仍然落后。
  • Fiber 的内存开销非常低（约 4 KB；文中提到 Go goroutine 约 2 KB）。
  • 用户报告称，相比 Ruby，在真实场景中可获得很大的性能提升（例如快约 40 倍、内存少约 3 倍），且只需极少代码改动。

用例与采用情况

  • 据报告的用途包括：内部 Web 服务、长期运行的服务器代理、CLI 工具、Minecraft 机器人、至少一家商业服务的搜索后端、小型服务器部署。
  • 长期生产使用情况褒贬不一：有人称其稳定；至少有一条反馈称因 I/O 期间异常相关的运行时问题而放弃 Crystal。

与 Ruby、Go、Nim 等的比较

  • 对于“更快的 Ruby”，TruffleRuby 和 Spinel 等替代方案被提及；Crystal 不是 Ruby 兼容的。
  • 一些 Ruby 用户更愿意留在 Ruby 上，因为生态系统更强，并认为对于 I/O 密集型工作负载来说，语言速度往往不是瓶颈。
  • 另一些人则看重 Crystal 的静态类型和编译期检查，它能尽早发现拼写错误并减少运行时意外。
  • 对一些人来说，Go 仍然更受青睐，因为它构建速度快、运行时成熟、网络库完善，而且现在还有 LLM 辅助开发。

开发体验、工具链与 OOP

  • 受到称赞的有：令人愉悦且富有表现力的语法、强大的标准库、C 互操作、编译期宏以及绿色线程。
  • 也有抱怨：编译时间慢；历史上 REPL 较弱（当前的 crystal i 仍被认为有限）。
  • 近期进展：Windows 安装程序/支持以及 aarch64-linux 已升为 Tier 1，使更多部署成为可能。
  • 围绕 OOP 的争论：有人希望有“普通的 OOP”来组织代码；另一些人则认为传统 OOP（以及隐式 null）是严重的设计错误。

LLM 与新语言的价值

  • 多条评论感叹，LLM 让学习小众语言的乐趣和职业回报下降，因为代理如今可以生成主流语言的代码。
  • 反方观点认为：你仍然可以选择手写代码；LLM 主要帮助入门和弥补文档空缺，而不是取代理解代码的必要性。
  • 更广泛的讨论张力在于：一方面对 Crystal 作为“爱的劳动”充满热情，另一方面又对它的长期相关性和差异化持怀疑态度。