Null Safety Debate

Is it too much to ask for null safety in the type system?

Implicit nulls are the underlying problem. If you default to non-nullable types and only allow nulls when explicitly annotated then it becomes much simpler to spot and handle all the cases where nulls might creep into your code. There are multiple ways of accomplishing that of course. Rust forces you to explicitly declare a variable as nullable and won't allow you to assign a nullable value to a non-nullable variable without performing a null check first. Haskell simply doesn't have a

It's more a failing of mainstream programming languages having nulls.

The problem isn't null/nil as such, it's when the type system treats null values as legal at compile-time.But if you look at e.g. Kotlin, or C# with "#nullable enable", it tracks whether a given reference can be null or not. So you write if-else code instead of match, but you have to do that in order to actually do something with a reference.

Surprised there's no mention of Kotlin here. It handles this really nicely, forcing you to declare if a value can be null and if it is null it requires a null check before it can be used (with some syntax sugar to make that cleaner)

Wouldn't using Koltin or Scala, which benefit from the engineering effort of JVM and arguably its ecosystem solve this problem ? (Since NULL is not idiomatic in either language)

Any type system that allows null or any shouldn't be trusted any more than a dynamic language

It's the same mistake as checked exceptions all over again. If you make null a special case in the type system then anything that interacts with the type system has to know about null or will handle it wrong. Far better to have the type system work with plain (non-nullable) values, and implement a plain old library type like Maybe/Option for use in places that need absence semantics; that way your concerns are properly separated and you can spend your type system complexity budget in m

Also missing null safety in modern language is weird.

Agree. It's not null that's the issue. Null can be fine, especially in a union type like Some|None (which in most languages is a type called Optional).It's mainly to do with languages that couldn't signify that some value could be null so you'd be forever doing defensive nullity checks. Developers get lazy or forgetful and miss out those checks when they need to be there; without language support, the compiler has no reason to assume that's a problem and lets cod