It's not just nulls. In C, you can compile and execute this without warning:

    int square(char* string) {
        int *number = (int*)(void*)string;
        return *number * *number;
    }

It's UB, so in principle it can do anything, and in practice, the best thing it might do is return gibberish.

The Java version of this would throw a ClassCastException on the first line.

I already said Java is safer than C. But neither language would catch that error _in the typesystem_; it's a runtime error in both languages.

And `head []` will explode at runtime in Haskell. How is it relevant? Type systems can never prove every interesting property of a problem. Yeah, nulls suck, but there is very good static analysis for Java.

The point is that Java doesn't seem that much more type safe than C.

I don't see how external static analysis tools are that relevant when we're talking about type safety.

I just don’t feel that it would be fair criticism, since by that definition, none of the following languages are safer than C: C++, C#, Java, JS, Go, even Scala. So basically the litany of languages having null..

All of those languages (possibly except for C++) are safer, in general, than C. But C#, Java, JS and Go aren't more type safe than C. I don't know how it works in Scala.

I just don't consider the language to be "type safe" when every single variable (except for primitives) can explode at runtime with no warning from the type system. At least with C++ you can have references which you know won't be null.

The fact that you bring up JS, a language with _literally no static type checking_, confuses me. Are we even talking about the same thing? Maybe I should've used the phrase static type safety rather than type safety? I thought it was clear from context (as a response to "with Java if it compiles it definitely works"), but maybe not.

> aren't more type safe than C

That’s just false. C has really “random” implicit casts everywhere, not having is already great.

And I agree with you that nulls are a huge mistake, but that’s one aspect of type safety.

> At least with C++ you can have references which you know won't be null.

Yeah, they are just uninitialized.

Java, if coded properly, ensures that a NullPointerException means that something went really, really wrong - in which case you're better off terminating than doing anything else. For variables that are expected to be missing occasionally, there are the Optional types or Collections/Lists, which I use extensively.

It’s an exception not an error, you can easily catch that, which may make sense eg. when you run third party extensions that should not bring down your whole program.