[vinceguidry]

Ugh. I have hardly any type problems in my Ruby code. I've gotten very good at recognizing implicit state and capturing it in a properly instantiated object with a well-named class. I daresay that if you don't have this skill, a type system isn't going to help you much and you're going to get nasty bugs anyway.

The problem in Ruby is nils, and you'd have the same problem with the same solution in a static language; creation of a duck type. You can't get away from duck types, whether it's a maybe type or whether you perform nil-checking at the earliest possible opportunity. You learn with time and experience how to deal with inconsistent data. Ruby gives me the flexibility to do it without a lot of boilerplate.

[pka]

Yes, a type system is very much going to help you, even if you have that skill of "capturing implicit state". Because then a function you call, written by somebody else without that skill, may rely on global state in unexpected ways and still blow up in production.

A good type system doesn't allow you to call impure code from a pure function. It just won't compile. So your skill becomes useless because it's automatically verified by the compiler.

[actsasbuffoon]

Nils are a problem in languages like C and Java, but more powerful type systems completely eradicate the issue. You might enjoy taking a look at Crystal. It has Ruby-like syntax and a type system that makes nil-checks completely unnecessary.

[vinceguidry]

Nils are only a problem when you're dealing with unclean data. The only way to eradicate the issue is to only deal with clean data. Otherwise you have to code the system to be able to handle it, whether through the type system or in another way. A type system helps, but so does discipline. I'll trade the productivity gains of dynamic typing over a babysitter any day.

A type system is just OOP with added math. The benefits don't outweigh the hassle. I've tried Crystal. Did not like. It was the language that taught me that there's more to Ruby than nice syntax.