I too wrote Ruby fulltime and professionally. For over a decade. The sheer amount of code I wrote, just to protect against nil-errors is staggering. Every thir

I too wrote Ruby fulltime and professionally. For over a decade. The sheer amount of code I wrote, just to protect against nil-errors is staggering. Every third function or method had guard clauses and/or tests. Just to ensure that the data was in the expected shape (that it quacked and walked like a duck). I spent, I think, hundreds maybe thousand hours debugging actual production "nil-errors" and weird conversion errors. That happened in production. Sometimes legacy database records, sometimes weird race conditions causing corrupt data, sometimes (most often) just stupid mistakes by me or another dev. All of these -all!- would have been caught by a typing system and type checker like e.g. Rusts'. All. Which then leaves just the huge category of stupid bugs that I'll make in the business logic. But now, working with rust, the LSP tells within ms that I overlooked something that In Ruby would've been a data-error. Often my Ruby test suite would find these after minutes of running. Sometimes we would find them after deploying to prod and seeing havoc. Sometimes they'd take weeks before popping up. I'm convinced rust makes me develop much faster because of this.