Ruby 4.0.0

Original Article ↗ Hacker News Discussion ↗

Overall sentiment & tradition

  • Many commenters express affection for Ruby and view Christmas releases as a long-standing tradition; several describe the release as a “gift.”
  • Some have moved away from Ruby in their day jobs (to Python, Kotlin, etc.) but still speak fondly of the language and hope for reasons to use it again.

Ruby::Box, Ractors & parallelism

  • Ruby::Box is seen as a low-level foundation for namespaced, isolated “container-like” execution; long‑term expectations include integration with refinements and possibly Ractors.
  • There’s active discussion on Ractors: some find the API awkward and adoption low; others describe successful high‑performance, low‑allocation use cases.
  • Core contributors say Ractors are now mostly bug‑free and truly parallel, with the main remaining bottleneck being global GC; “Ractor local GC” is planned but missed 4.0.
  • Ruby::Box is not yet a GIL solution and may actually add indirection; its performance impact and final shape are still described as “unclear.”

Fibers, Rails & concurrency in practice

  • Fibers are considered more mature and somewhat used (e.g., Falcon, Async), but real‑world gains can be negligible if servers are configured in “Unicorn mode” with no concurrency.
  • For typical Rails apps, commenters argue fibers mostly matter for specific workloads (e.g., highly concurrent async DB queries), which many setups don’t fully exploit.

Typing: RBS, Sorbet & alternatives

  • Ruby has RBS (separate type files) and Sorbet (inline types + runtime checks). Some teams report significant benefits: fewer tests, better refactoring, and LSP integration.
  • Others find Sorbet painful: verbose, brittle around gems, pushing code toward “Java‑like” rigidity and larger methods, with poor DX vs. TypeScript or even typed Python.
  • Several argue that if you “need” static typing, Ruby may not be the right language; they value Ruby precisely for avoiding annotations and letting tests handle most issues.
  • Newer projects like low_type and other experimental systems are praised as more ergonomic “TS‑like” approaches, but adoption is still early and contingent on big users.
  • Some believe partial typing in dynamic languages gives the downsides of both worlds; others strongly disagree, citing concrete productivity and correctness wins.

Ruby vs Python & ecosystem debates

  • Multiple commenters say they switched to Python for ecosystem reasons: FastAPI, scientific/ML/AI stacks, stronger typing tools, and superior editor/IDE support.
  • Others counter that Ruby is often faster than Python, has long‑standing better package management and metaprogramming, and fewer language “warts.”
  • There’s consensus that Python’s larger community and library ecosystem dominate in data/AI; Ruby is perceived as centered on Rails, despite claims that FFI makes most native libs accessible.
  • One thread notes that Python’s popularity is driven more by its ecosystem than by language design, while Ruby’s community is portrayed as people who genuinely like the language itself.

Tooling, LSP & DX (especially on Windows)

  • Tooling quality is described as “below expectations,” particularly on Windows; some recommend WSL2 plus Docker and Dev Containers as workarounds.
  • Ruby LSP is highlighted as improving rapidly, now supporting “go to definition” and sharing a common AST/index for other tools.
  • IDE discussion: Python benefits from strong free tooling (e.g., PyCharm Community), whereas RubyMine historically required a license; RubyMine is now free for non‑commercial use.
  • IRB vs IPython: one commenter prefers IPython and wants better REPL DX; others ask what specific IRB gaps exist, implying this is still an open question.

Language features & syntax tweaks

  • Ruby::Box is seen as promising for running multiple versions of features/rollouts in the same process.
  • New multi‑line conditional syntax with leading &&/|| is widely praised for readability and easier diffs (delete/add whole lines without touching previous ones).
  • Some note they already broke conditions across lines; others say the new style favors scanning by line starts and improves merge behavior.
  • Internal stack traces are cleaner in 4.0; several want relative paths next.
  • The Set class getting more prominence is welcomed.
  • Multi‑line comments (=begin / =end) are pointed out as already existing, even as others wish for them.

Versioning, expectations & compatibility

  • Some feel 4.0.0’s changes are modest compared to the Ruby 3 “3x3 performance” push and say it feels more like “3.5” in substance.
  • Others respond that the major bump is partly celebratory (30 years of Ruby) and Ruby doesn’t follow strict semver.
  • The jump to 4.0 causes practical issues for gems that hard‑lock Ruby versions (e.g., < 4.0 or < 3.5), blocking early adopters until gem authors update constraints.

Usage, learning & resources

  • Rails remains a major draw for full‑stack development; some praise Ruby’s metaprogramming for building high‑level abstractions (e.g., APIs defined from a markdown file).
  • Recommended learning resources include video courses like Pragmatic Studio’s Ruby/Rails tracks.