I Love Ruby

Ruby’s focus on developer happiness, expressive syntax and DSL-friendly features still inspires deep affection, especially for rapid prototyping and web work with Rails, but it also raises concerns about maintainability, implicit behavior and weak tooling compared with modern typed ecosystems. Commenters contrast Ruby’s “reads like English” style and powerful metaprogramming with the safety and IDE support of languages like Rust, Kotlin, TypeScript and Python, often citing type systems and explicitness as reasons they’ve moved away. Much of the debate centers on trade-offs between productivity and long-term clarity: joyful, concise code versus the challenges of debugging magic, reasoning about globals, and working in large, long-lived codebases.

Overall sentiment

  • Many commenters say Ruby is uniquely joyful and productive, especially for “getting things done” and prototyping.
  • Others actively dislike working in Ruby, particularly in large or legacy codebases, citing maintainability issues and “magic.”
  • Several people no longer use Ruby day‑to‑day but retain a strong affection for it.

Expressiveness and syntax

  • Supporters highlight Ruby’s “reads like prose” style, predicate methods with ?, blocks/yield, and chained Enumerable operations as highly expressive.
  • Critics argue that “reads like English” is overrated; natural language is imprecise, and DSL-heavy code can be harder to follow than plain code.
  • There is debate over what “expressive” even means; some tie it to DSL/metaprogramming power, others see it as a vague label for “I like this language.”

Types and tooling

  • Many moved from Ruby to Rust, TypeScript, Kotlin, etc., saying they can’t live without strong static typing anymore.
  • Ruby’s gradual typing story (Sorbet, RBS) is widely seen as clunky or painful; some feel Ruby “needs” better built‑in types, others say that would betray its message‑passing nature.
  • Tooling is perceived as weaker than typed ecosystems: jump‑to‑definition and static analysis are brittle, especially in Rails/metaprogrammed code. Some note newer LSP/debug tools are improving this.

Metaprogramming, “magic,” and maintainability

  • Ruby (and especially Rails) is praised for powerful metaprogramming and DSLs (RSpec, Cucumber, Rails routes/validations), which feel elegant and concise.
  • The same features are blamed for opaque, implicit behavior: dynamically generated methods, heavy use of inheritance, global mutable state, and deep abstraction chains make local reasoning hard.
  • People describe difficulty tracking where a method is defined or why something happens; others counter that runtime introspection (pry, method(...).source_location) is the intended workflow.

Comments and documentation

  • Strong disagreement over “code as documentation.” Some Rubyists write few comments and rely on clear, high‑level code and DSLs.
  • Many argue comments are essential for explaining “why,” design decisions, and non-obvious constraints; absence of such comments is seen as a maintainability smell.

Performance, ecosystem, and jobs

  • Some say Ruby’s performance is usually good enough for web work, where DB or network latency dominates; others prefer faster or more typed languages for serious backends.
  • Ruby is praised for a pleasant ecosystem and friendly community, but several perceive a decline in Ruby/Rails job opportunities versus TypeScript/React and other stacks.