It's kind of a tradeoff, right? How many years worth of work are you willing to rewrite, just to get rid of a little cruft? Choose your language wisely and you'll have no problems.
You are assuming that the changes would take years. Doesn't it really depend on the changes? Some could be automated? Perhaps a switch/flag could be set within the language itself. If C# became safer, for example, how would you weigh the tradeoffs?
> That would be huge, and worth any amount of hit.
I'm open to the idea that non-nullable references (by default) could 'be worth any hit', but I'd like to see the evidence. Have you tested converting a large codebase to non-nullable, and seen a reduction in errors as a result?
I have. Obviously it's not possible to do this completely in C#, but my team has moved over to using Option, Try, and Either types for values that might be null or throw exceptions. We've noticed a reduction in what we all knew was the single most common bug: null reference exception. It also reduces cyclomatic complexity [1], which is a fairly well understood measure of complexity and therefore bugs.
Anecdotally I've noticed a reduction in these kinds of issues when using languages that use non-nullable references by default (F#. Haskell, etc.). I find I am much more confident as a programmer when nullable references aren't the default. Actually a few days ago we had our first null reference error in F#, and it was because the record type passed to an F# function was instantiated in C#.
If you think about it, the idea that a statically typed system lies to you about the contract that a value will honour is always going to be a source of bugs. It takes static languages back into the realm of dynamic languages.
