NULL/missing is so common that it makes sense to provide special language support, even if you don't have full unions. See e.g. Kotlin and Typescript.
What doesn't make sense is to treat a nullable type the same as non-nullable type causing errors everywhere (Java), or make it so special that it basically has completely separate logic and operators attached (SQL)
A lot of confusion comes from SQL nulls having the same name as nulls in programming languages. They are conceptually completely different things.
Nulls in programming languages are a special “sentinel” value indicating the lack of an object. Nulls in sql means “unknown” or “I am not able to answer that question”.
This is why in most programming languages two nulls are equal, since they are the same sentinel value. Not so in SQL, since one unknown value is not necessaily the same as some other unknown value.
JSON does not define a type system, but javascript defines null as the only value of the null type. This works fine in eg typescript since you can use a type union of null and any other type, if you want to indicate a nullable value.
Typescript does have full unions, although only partially discriminated ones (in the sense that `number | string` is discriminated but `number | number` is not - custom discriminators can be written fairly easily though). This resolves the problem that the previous poster had - nullability is not some magic trait of certain types, but rather a function of the general case of union types. In that case, `string | null` is no different from `string | number`, and null is just one possible type among many.
> NULL/missing is so common that it makes sense to provide special language support, even if you don't have full unions. See e.g. Kotlin and Typescript.
No it doesn't. It's a bad idea in programming languages just as it's a bad idea in SQL.
Given that a lot of non-niche modern languages disagree with you and you provide no rationale, I remain unconvinced.
Swift, Kotlin, Javascript/Typescript along with some older languages (PHP, C#, probably more) have special null-handling in the language. Go and Rust do it differently, but do have an extremely strong opinion on how missing values should be handled.
There are tradeoffs - if you go against the zeitgeist and ban nulls then you risk people you need to please for success sticking their nose up at you. It is a bit like car safety features - if it is such a good idea why wasn't it taken seriously until say the 90s.
What doesn't make sense is to treat a nullable type the same as non-nullable type causing errors everywhere (Java), or make it so special that it basically has completely separate logic and operators attached (SQL)