"Useless Ruby sugar": Argument forwarding
Ruby’s new argument-forwarding syntax using `...` polarizes developers between those who see it as elegant, low-maintenance sugar for wrapping and delegating methods, and those who view it as unnecessary complexity that hurts readability. The exchange broadens into a critique of Ruby’s overall design—its many calling conventions, blocks, and evolving syntax—contrasted with languages like JavaScript, Python, Go, and Clojure, and tied to deeper questions about simplicity, “magic,” and how much syntax a mature language should keep adding. Several commenters also touch on optional static typing and type systems (e.g., Sorbet, TypeScript) as an alternative axis for improving robustness instead of new syntactic features.
Overall reception of the article and feature
- Many commenters enjoy the series and see the argument-forwarding
...syntax as elegant, expressive, and helpful for real-world Ruby (e.g., Rails service objects). - Others find the new sugar ugly, confusing, or “useless,” especially when coming from older Ruby versions or preferring minimal, explicit syntax.
Ellipsis ... vs “code omitted” convention
- Several people note confusion because
...is both valid Ruby syntax and a common convention for “code omitted.” - Various alternatives are suggested:
- Using spaced
. . ., comments, or textual markers like[..trim..]. - Relying on language features like Rust’s
todo!or Python’s...as a placeholder.
- Using spaced
- Multiple languages are cited as already using
...for variadics/spread, so some argue Ruby is not breaking any “industry standard.”
Ruby’s argument and block model
- Explanations clarify Ruby has:
- Positional and keyword arguments, plus an optional block.
- Historical quirks around hashes vs keywords, cleaned up in Ruby 3.
- Blocks vs procs vs lambdas are discussed:
- Blocks are implicit closures with special return semantics.
- Procs/lambdas are explicit callable objects, with different control-flow behavior.
- Some see three “function-like” abstractions as overcomplicated; others view them as powerful and intuitive once learned.
Design quality: Ruby vs other languages
- One side argues Ruby’s multiple calling conventions and sugars indicate flawed or overgrown design compared with simpler models (e.g., “just pass objects and functions” as in JavaScript).
- The opposing view:
- Ruby’s syntax and semantics are seen as carefully thought out and highly readable.
- Many languages of the same era made awkward choices; Ruby is not uniquely bad.
- Ruby offers a high ceiling for elegant DSL-like code, but also a very low floor for unreadable “magic.”
Static typing and large systems
- Some argue Ruby should prioritize optional static typing; others claim two type systems inside one language are poor engineering.
- TypeScript and Python’s type hints are cited as successful; Sorbet and other Ruby typing tools are seen as helpful but less powerful.
- There is sharp disagreement over whether static typing is essential for large, long-lived systems or an overvalued, slow-feedback practice.