Ruby 3.3

Ruby 3.3 的意义

• 许多人认为 3.3 是过去十年来最重要的 Ruby 版本：可用于生产的 YJIT、Prism 解析器、更好的 IRB、fibers/async，以及 Ractors。
• 也有人并不买账，追问除了渐进式的速度和工具改进之外，究竟有什么根本性的创新。

性能、YJIT 与基准测试

• 有报告称，在启用 YJIT 后，大型 Rails 应用的速度提升了 10–15%；在某些 CPU 密集型负载上，微基准测试显示性能提升 2–3 倍。
• 批评者认为，即便有这些提升，Ruby 仍然比 Go/Java/Rust 慢几个数量级，这也不会改变 Ruby“慢”的名声。
• 反方观点：在典型 Web 应用中，延迟主要由数据库/IO 决定；Ruby 已经“足够快”，而且服务器成本通常相较于开发者时间并不算大。
• 有些人举出实际案例，在不算大的规模下，Django/Rails 的开销和资源使用确实成了瓶颈。

并发与运行时（Ractors、Fibers、RUBY_MAX_CPU）

• Ractors 和异步 fibers 被视为被低估的大特性，不过它们在 Rails 中的实际采用情况仍不明确。
• 新的 RUBY_MAX_CPU 默认值为 8；有人希望它与逻辑核心数挂钩，也有人指出核心数可能被错误报告，因此更倾向于保守默认值。
• 名称解析（getaddrinfo）现在在工作线程中运行，因此可以被中断；这会带来轻微开销，但能实现异步行为。

工具链：Prism、LSP 与调试

• Prism 解析器被称赞为更快静态分析、RuboCop 集成以及语言服务器的基础。
• IRB 获得了重大改进（自动补全、调试），Ruby 的调试工具（rdbg、Pry）也被重点提及，不过重度元编程仍然很难调试。

任务队列与跨语言互操作

• 不少人惋惜 Ruby–Python 集成缺乏一个事实上的跨语言任务队列；许多团队只是分别使用 Sidekiq（Ruby）和 Celery（Python）。
• 提到的选项包括：基于 Redis/RabbitMQ 的语言无关系统、Faktory、Celery 的协议、beanstalkd、Gearman、dirq、SQS，以及基于 Postgres/Redis 的自建队列。
• 关于商业化也有争论：一些“必需”的可靠性特性（例如崩溃时不丢任务）被放在付费层后面，有人对此不满，也有人认为这是维持可持续性的必要做法。

导入与全局命名空间

• Ruby 单一的全局常量命名空间以及缺少模块导入机制，引发了不同看法。
• 有人喜欢 C 风格的“直接加载文件”和 Rails/Zeitwerk 的自动加载约定；也有人更偏好 Python 风格的显式导入，并认为 Ruby 的常量解析很笨重。
• 一些实验性库和提案正在尝试更显式、模块化的导入语义。

生态健康与使用场景

• 一种强烈观点认为，Ruby/Rails 在多年前就已达到高峰，相比 Python、TypeScript、Go、Rust 和 Java/Spring 正在长期下滑；许多 Web 团队已经转向别处。
• 另一种观点则认为，虽然它不再是 2007–2009 年的巅峰状态，但 Ruby/Rails 稳定甚至在复苏——新的大会、书籍、gem 和特性（Rails 7、Hotwire、Turbo 8）表明社区依然活跃。
• 普遍共识是，大多数 Ruby 使用仍然是 Rails Web 应用；非 Rails 使用场景（CLI、基础设施、安全工具、配置管理）确实存在，但相对小众。

Ruby 与其他语言：速度 vs 生产力

• 一派强调 Ruby 的慢速和不断缩小的就业市场，认为对性能敏感的严肃工作应该放在 Go、Rust、Java、C# 等语言中。
• 另一派看重 Ruby 的表达力、强大的标准库（Strings/Arrays/Hashes）、测试文化（RSpec/MiniTest）以及“开发者幸福感”，认为在大多数业务应用中，生产力和简洁性比原始速度更重要。
• 有人指出，Go/Rust 可以在高负载 API 场景下显著减少服务器数量，但也承认它们会带来更慢的迭代速度和更陡峭的学习曲线。

学习 Ruby 与“更好的 Bash”

• 建议各不相同：如果已经在 Python/Node 中高效工作，Ruby 可能不会解锁根本不同的能力，但它很有趣，也很优雅。
• 不少人称赞 Ruby 是用于脚本、文本处理和探索性系统工作的“更好的 bash/Perl”，尤其适合配合 Pry/IRB、Sequel，以及强大的 enumerable API。
• 也有人觉得 Ruby 的语法、block 和元编程文化比 Python 更极简、以函数为中心的风格更难上手。