This! 100% This is why code review and strict linters( i.e. Rubocop) are an absolute must for any large ruby code base.
Types do help in that this would be visible as it's happening with the parameter list and allowed types list getting longer and longer or uses of untyped.
A similar thing with highly overloaded types could happen in type-inferred languages but compile errors catch when expectations don't match.
For something like Ruby types feel bolted on and for the trouble I'm not sure the payoff is worth it personally.
But this is all just my opinion, clearly a lot of smart folks a Shopify disagree.
The other difference is that I can not add a validation and the code passes existing tests and runs. Typecheck won't pass without making the messy longer type sig or writing the untyped smell.
I hadn't read anything about productivity of different languages and team sizes--if you have any references I'd be interested in reading them.
One story I did read was about how Twitter switched to Scala (and later Java IIRC) mainly for the static typing and not for performance or other reasons.
I don't understand the not seeing it in a large codebase point. I work on a large Ruby code base that started without type annotations. Since I joined, we're now all adding type annotations for everyone's benefit, so they definitely exist. The reason for not wholly rewriting such a large codebase in a static typed language should generally be considered a no go. Many devs complained at the time and now most (if not all, I don't know of exceptions) now appreciate having the type checking and visible annotations for reading. I don't work on front-end but I expect that there was a some of that too in the React TypeScript codebases.
What do you mean by this?
It’s inherently a part of Ruby, a feature one might say, that you can probably spin up a full functioning web application from Front End to Database in hours. This type of speed setup and launch inhibits not even thinking through design principles or other people coming back to read or work on the code.
Furthermore, because everything can be an object you end up writing boiler plate checks for nil values all over the place or don’t and ignore those cases that later crash the entire process running.
Most of these issues are not prevalent in strongly typed languages because, other than custom objects, what you define is what you get.
If speed is your only priority, say a startup, I would never just go throwing untyped Ruby code around because it’s gonna cost you in the long run trying to get others to work on your code.
I've written a LOT of ruby over the years, and honestly bugs related to objects being the wrong type were in the minority. Yes, something popping up as nil in a weird place did happen, but not that often and it's usually easy to fix.
Ruby has a lot of ways to express the type of information you're passing around. The problem is when you don't validate things coming from users, APIs, and the database, or if you muddy you state in some overburdened god-object. I think the problem is that its so easy to write Ruby code and it less you do almost anything you want, so it is very easy to make a mess. Types may or may not help.
I've worked in some big Rails/Ruby code bases and usually any mess was the result of someone who didn't know the language writing a bunch of code alone with little to no code review or guidance.