That comment is expected by a Ruby enthusiast, which is arguably one of the most dynamic languages in existence.
I think that comment is clear in that he likes to work alone which for problems of a certain size just isn't feasible
I have migrated to TypeScript just about a year ago and it's my third try to migrate to TS from JS during the last decade and finally a successful one. While TS went a long road since the first versions which were incredibly hostile, my rewrite of a large codebase from js to ts revealed exactly zero type-related bugs.
1. 20% were type-coercion bugs, 30% were non-boolean values being passed to boolean-named fields (with some overlap with the former). Linters have come a long way, but compile-time type-checking is better in almost every way.
Static types are IMHO more useful for speed, maintenance/refactoring of large projects, and code completion in IDEs. But a codebase in production is unlikely to have much type related bugs...
I don't think that's an acceptable way to treat your users. If something is trivial to prevent, do it.
The concept of them being more than compiler bookkeeping, but as propositions about program behavior and invariant encoding is more than 50 years old at this point.
Me when my manager asks to complete the JIRA ticket.
What IDE/LSP do you use? I was on VSCode/ruby-lsp and disabled sorbet, but after working with Zod, I became quite intrigued with the value of letting the schema do a lot of the guarding. I was under the impression that things like Crystal (statically typed Ruby) were not in vogue, and that the reason no one was moving toward static typing was because Matz did not give his blessing.
(Just checked sorbet landing page, looks like it's mainly/only for fn signatures?)
A lot of Rubyists deeply care about code aesthetics and Sorbet annotations are unfortunately quite ugly. There are also RBS comments, which look a bit better, but tooling/LSPs are not quite there yet IME.