Ruby 3.3

Original Article ↗ Hacker News Discussion ↗

Ruby 3.3’s release is seen by many as the most significant in a decade, bringing a production-ready JIT (YJIT), the new Prism parser, improved IRB tooling, and stronger async and concurrency primitives such as fibers and Ractors. Commenters debate whether these gains materially change Ruby’s reputation for poor performance—especially compared to Go, Rust, Java, and Python—and how much Rails and its ecosystem, rather than the language itself, are to blame for slowness and declining mindshare. Others argue Ruby and Rails remain highly productive for web backends and scripting, with performance now “good enough” for most business workloads, even if not competitive in raw benchmarks.

Significance of Ruby 3.3

  • Many see 3.3 as the most important Ruby release in a decade: production-ready YJIT, Prism parser, better IRB, fibers/async, and Ractors.
  • Others are unconvinced, asking what is fundamentally new beyond incremental speed and tooling.

Performance, YJIT, and Benchmarks

  • Reports of 10–15% speedups on large Rails apps with YJIT enabled; microbenchmarks show 2–3x gains on some CPU-bound workloads.
  • Critics argue that even with these gains Ruby remains orders of magnitude slower than Go/Java/Rust and that this won’t change Ruby’s “slow” reputation.
  • Counterpoint: in typical web apps, latency is dominated by DB/IO; Ruby is “fast enough,” and server cost is often minor versus developer time.
  • Some describe real cases where Django/Rails overhead and resource use did become a bottleneck at modest scale.

Concurrency & Runtime (Ractors, Fibers, RUBY_MAX_CPU)

  • Ractors and async fibers are seen as under-discussed big features, though practical adoption in Rails remains unclear.
  • New RUBY_MAX_CPU defaults to 8; some want it tied to logical cores, others note misreported core counts and prefer a conservative default.
  • Name resolution (getaddrinfo) now runs in worker threads so it can be interrupted; this adds slight overhead but enables async behavior.

Tooling: Prism, LSP, and Debugging

  • Prism parser is praised as a foundation for faster static analysis, RuboCop integration, and language servers.
  • IRB gets major improvements (autocompletion, debugging), and Ruby’s debug tooling (rdbg, Pry) is highlighted, though heavy metaprogramming remains hard to debug.

Job Queues and Cross-Language Interop

  • Several lament the lack of a de facto cross-language task queue for Ruby–Python integration; many shops simply use Sidekiq (Ruby) and Celery (Python) separately.
  • Mentioned options: a language-agnostic Redis/RabbitMQ-based system, Faktory, Celery’s protocol, beanstalkd, Gearman, dirq, SQS, and Postgres/Redis DIY queues.
  • Debate over monetization: some “must-have” reliability features (e.g., not losing jobs on crash) sit behind paid tiers, which some dislike and others defend as necessary for sustainability.

Imports and Global Namespace

  • Ruby’s single global constant namespace and lack of module imports divide opinion.
  • Some like C-style “just load files” and Rails/Zeitwerk autoloading conventions; others prefer Python-style explicit imports and find Ruby’s constant resolution unwieldy.
  • Experimental libraries and proposals attempt more explicit, modular import semantics.

Ecosystem Health and Use Cases

  • Strong view: Ruby/Rails peaked years ago, is in long-term decline versus Python, TypeScript, Go, Rust, and Java/Spring; many web shops have moved on.
  • Opposing view: while not at its 2007–2009 peak, Ruby/Rails is stable or recovering—new conferences, books, gems, and features (Rails 7, Hotwire, Turbo 8) indicate a lively community.
  • Consensus that most Ruby use is still Rails web apps; non-Rails usage (CLIs, infrastructure, security tools, config management) exists but is niche.

Ruby vs Other Languages: Speed vs Productivity

  • One camp emphasizes Ruby’s slowness and shrinking job market, arguing serious performance-sensitive work belongs in Go, Rust, Java, C#, etc.
  • Another camp values Ruby’s expressiveness, strong standard library (Strings/Arrays/Hashes), testing culture (RSpec/MiniTest), and “developer happiness,” arguing that productivity and simplicity outweigh raw speed in most business apps.
  • Some note Go/Rust can reduce server counts dramatically for heavy APIs, but also acknowledge slower iteration and steeper learning curves.

Learning Ruby and “Better Bash”

  • Recommendations vary: if already productive in Python/Node, Ruby may not unlock fundamentally new capabilities but is enjoyable and elegant.
  • Several praise Ruby as a “better bash/Perl” for scripting, text processing, and exploratory system work, especially with Pry/IRB, Sequel, and strong enumerable APIs.
  • Others find Ruby’s syntax, blocks, and metaprogramming culture harder to approach than Python’s more minimal, function-centric style.