Ruby 3.4.0

Original Article ↗ Hacker News Discussion ↗

Ruby 3.4.0’s release highlights a major shift to a new hand-written parser (Prism) and continued work on the YJIT compiler, promising better performance, flexibility and error reporting for a language already prized for developer productivity. Commenters weigh the trade-offs between parser generators and hand-rolled parsers, debate JIT and GC maturity compared with JVM and .NET, and explore how Ruby’s ergonomics, Rails, and rich DSL capabilities stack up against ecosystems like Python and Node.js. Practical concerns around installation, tooling, and long-term stewardship (including skepticism toward Oracle-led TruffleRuby) round out a broader reflection on Ruby’s place in modern software development.

New parser (Prism) and parsing debate

  • Many are excited about Ruby 3.4’s switch from the old yacc-based parse.y to the hand-written prism.c parser.
  • Some argue hand-written parsers are clearer, easier to debug, and ultimately more maintainable than parser generators, despite larger LOC.
  • Others defend parser generators for:
    • Detecting ambiguities and conflicts in grammars.
    • Handling edge cases and being “battle-tested.”
  • Concerns raised: hand-written parsers can silently encode ambiguities; parser generators improve grammar clarity but their tools are often “black boxes” and not portable across ecosystems.

Error messages and developer experience

  • A major benefit expected from Prism is better syntax error reporting.
  • Generated parsers (yacc/bison) are criticized for poor error messages; custom parsers can embed richer, context-specific diagnostics, though this is non-trivial research-wise.

Performance, JIT, and GC

  • Users praise recent Ruby performance gains, especially YJIT, which significantly speeds up Rails workloads.
  • Discussion of JITs compares YJIT with V8, JVM HotSpot, .NET RyuJIT, TruffleRuby, JRuby, and others; consensus is Ruby’s JIT is catching up but still behind long-mature engines.
  • Some see Ruby’s GC as “good enough” given the GIL and typical Rails workloads, but there is interest in pluggable GCs (e.g., MMTk) and comparisons to advanced JVM collectors.
  • Shopify’s large-scale use of Ruby/YJIT is cited, though there’s disagreement on how much Ruby vs I/O and architecture are the real bottlenecks.

Ruby’s strengths and “niche”

  • Ruby is framed as a general-purpose, highly productive language with:
    • High “useful work per LOC” and concise syntax.
    • Powerful OO model and metaprogramming enabling DSLs (e.g., 3.days.ago).
    • Rails as a “killer app” for fast CRUD/admin web apps and “developer happiness.”
  • Some argue Python “won” due to data/ML, but consider Ruby a nicer language; others dismiss Ruby as niche or “dead,” with counterexamples of many well-known companies still using it.

Tooling, installation, and platform issues

  • Newcomers report difficulty installing modern Ruby/Rails (especially on Windows) and getting editor tooling like ERB highlighting working, leading to frustration.
  • Others recommend version managers (asdf, mise, rbenv, rvm), Docker, or WSL, and say Ruby works best on macOS/Linux; native gems on Windows are still painful.

Typing and future direction

  • Some wish for a TypeScript-like static type system in Ruby 4.
  • Core ecosystem figures reportedly favor Ruby’s dynamic nature; RBS, Sorbet, and runtime type-checking libraries are seen as optional tools rather than a direction for the language.