What's New in Ruby on Rails 8

Original Article ↗ Hacker News Discussion ↗

Rails 8 vision and philosophy

  • Talk and official blog are widely recommended: emphasize “no PaaS required,” comfort with servers, and rejecting industry fads (over‑engineered infra, microservices everywhere, DIY auth).
  • Many appreciate Rails’ willingness to go against mainstream trends and focus on developer happiness and simplicity.
  • Others see the rhetoric as deliberate “pick a fight” marketing, similar to earlier battles against Java EE.

Solid stack & moving away from Redis/PAAS

  • Solid Cache/Job/Cable/Search aim to run caching, jobs, WebSockets, and search on SQLite/Postgres, removing Redis/Elasticsearch for many apps.
  • Pros cited: huge cache capacity on cheap DB storage (claims of multi‑TB cache with ~0.5 ms extra latency), simpler ops, lower cost, “lean stack by default.”
  • Skeptics will keep Redis/Sidekiq/Elasticsearch for existing production systems; new stack seen as promising but too early for some.

Rails vs microservices and modern JS stacks

  • Strong pushback against microservices as default; many argue monolithic or “modular monolith” Rails apps are simpler, faster to ship, and enough for most companies.
  • Others argue microservices mainly solve team‑scale and codebase‑scale problems; debate over whether they ever made sense for “performance.”
  • JS/Node world is seen as powerful but cognitively heavy (packaging, bundlers, transpilers). Some report comparable productivity with Next.js + ecosystem, but only after significant complexity.

Ruby/Rails productivity, performance, and typing

  • Many long‑term users say Rails still offers unmatched dev velocity, thanks to conventions, generators, and rich batteries (ORM, jobs, mail, assets, etc.).
  • Critics focus on Ruby’s dynamic typing, monkey patching, and metaprogramming as “sharp knives” that lead to fragile, hard‑to‑refactor codebases, especially as projects age.
  • Static‑typing fans migrate to C#/Go/TS; some use Sorbet and report real benefits, but note rough edges, limited ecosystem types, and slower evolution than TypeScript.
  • Performance discussion: Ruby historically slow but improved (YJIT, ecosystem work); still generally slower than C#/Node in benchmarks, but many argue real‑world bottlenecks are design and DB, not Ruby itself.

Docs, ecosystem, and adoption

  • Several complain Ruby and Rails docs are confusing or incomplete (WIP tags, poor structure) compared to Python/Django; this discourages newcomers.
  • Others note a “renaissance”: new book editions, scaling guides, async work (Fibers/Falcon), Rails 7–8 momentum, but also acknowledge Ruby’s GitHub ranking has slipped.
  • Common theme: popularity charts matter somewhat (hiring, vendor SDKs), but many still choose Rails for joy, stability, and the ability for small teams/solo devs to ship full products quickly.