A substantial number of bugs I see where a method is called on nil are business logic errors that result in something not being where it's expected, and those bugs would just manifest differently at runtime with static typing. Every web app I've ever seen in a statically typed language has plenty of logic relying on "unwrap nullable or raise error" mechanisms.

That may be your experience. It's not mine. Null-safety forces you to think about the exceptional case (and whether it is supposed to occur at all). If you do so poorly, yes, you'll have errors too. But it's not something that can happen to you by accident.

For example, if you have a method A that gets a foo from the method B and then does something to that foo, you might get a runtime error if B returns nil. If this happens over dozens of method calls, it can start to become very hard to see where the error was introduced.

But if you know that B is always supposed to return foo and never nil, then the compiler can show you where the error in your definition of B is ahead of time.

The value of null-safety is not in making everything nullable and then just proceed with unwrapping etc., the value is that we can make a lot of types explicitly non-nullable.

I don't think it's controversial that a good type system allows to verify more soundness guarantees at compile time. The only controversy is whether it's worth the effort.

I agree with you about the value of static typing and non-nullability, don't get me wrong. My experience is just that _web development_ and other use cases traditionally favored by dynamic interpreted languages tend to have a lot of unexpected nulls of a type that are not prevented by strict typing. There are other types of bugs that I absolutely expect to see less of with strict typing.

I agree, I think it’s a good reason to use the static typing in Ruby > 3.0.

Any static analysis tool you can use to catch bugs before runtime in production is something we want.