A critical look at the trend of adding types to Ruby — Sorbet, RBS, and others — and why forcing static typing into a dynamic language misses the point.

RubyFlow's platform is a resource for Ruby developers, offering insights into Ruby programming language, Ruby on Rails framework, and Ruby-related tools. Through articles, tutorials, and community discussions, RubyFlow offers insights into building web applications with Ruby and Rails. Developers can learn about Ruby gems, Rails conventions, and best practices in Ruby development to write clean and maintainable code.

Ruby Flow

Ruby's dynamic nature and duck typing philosophy make static type systems like Sorbet and RBS counterproductive. These tools introduce runtime overhead, code noise, and maintenance complexity while contradicting Ruby's core design principles of message passing and flexibility. Instead of forcing type annotations, developers should embrace duck typing, use YARD for documentation, write comprehensive tests, and employ linters like RuboCop for code quality. The push for static typing in Ruby reflects a broader cultural problem of adopting tools for their own sake rather than understanding the language's strengths.

You Don’t Need Types in Ruby

Even though I agree, why not let people write the code THEY want to write. If that’s Ruby with types then that’s their decision.
It serves a purpose in large codebases, and not everybody is a coding god. Sometimes you need that extra safety in large codebases.
Especially the last sentence, about caring about the climate and type checking… lol 🤣

<blockquote>
you don’t care what it is, only what it can do.
</blockquote>
That’s still Something types are very useful for, to know what you expect and what i can expect back.
<blockquote>
checkout(Cash.new, 50)
</blockquote>
checkout(Cash.new, 50$) 
checkout(Cash.new, 50€) 
checkout(Cash.new, (50$/month)) 
checkout(Cash.new, 50ct)
<hr>
Granted my general solution is indeed to just not use Ruby, but sometimes you have to e.g. due for legacy code and still want valid contracts

Seems like the same arguments that people use against TypeScript.
For writing your own code - just do it in a way you like it, but with codebase with more than 2 people in it having some hints about what property should be what type helps significantly.

Man when you do a project with many member it’s a nightmare without typesafe, like working a pj with js. Ez for you but nightmare for others