The way I describe language types to non-coders inquiring about language selection for a given project is simply “scale matters”… dynamic types provide flexibility at small scale, but can very easily result in chaos at a large scale. Conversely, the structure of static types can feel onerous and restrictive at small scale, but provide robustness and structure at large scale.
If you mean codebase complexity and team size... then yes... types is more helpful with that. But in a small team with a small codebase you don't need types to do really well. I find types helped a lot when multiple teams were responsible for different domain spaces inside different components of a Rails app. I never saw the same advantage in codebases that are much smaller with fewer people.
I see what you mean but I have never found it to be an issue even in large codebases. Sorbet and RBS have been problematic. Lots of development slows down with these solutions. I wished it had something baked into the language as well but I'm happy without... just following conventions alone has worked really well for me.
Yeah I just can't go back. How fast you can confidently refactor and the improved tooling is the biggest thing for me
You can do fine without them - Basecamp proved that. There's a good reason basically every other Rails company eventually moved to static typing though
This is a great presentation/article, thank you for posting it since I haven't seen it go by elsewhere.
What holds me, personally, from Sorbet is the fact that it tries (unwillingly) to dictate which features of Ruby are "bad" by not supporting them - specifically, "prepend" and Refinements. Now, Refinements I havent' seen used in the wild, but "prepend" I use the living hell of - both when designing modules and when overriding other libraries (with moderation, and when I do it is gawddam' well necessary).
While I can appreciate opinions, I am not really motivated to adopt a tool which snaps me on the fingers because I use the tools I know the utility of. I am not working at Stripe nor at Shop :-) Another thing I could really appreciate would be ad-hoc interfaces a-la Go - and more support for duck-typing in general. Maybe I missed this in Sorbet, but it seemed the idea was to "inherit like you are told to and shut up" - which is not how truly great things can get done in Ruby, at least in my experience.
Interesting to see where Sorbet goes in the coming years - and stoked for more RBS/Sorbet interplay!