It's not that bad. Sure I'd call parts of it broken, but this isn't it:

> any type might silently be another type which doesn't support any of the methods the static type would indicate

When an object is typed differently from its actual runtime type, it's usually because it's hidden behind an interface type. So it indicates fewer methods than it supports. Safe, but unergonomic!

No, every object can be null, which just doesn't support any of the advertised method. You can have a `Frobnicator frobnicator` variable where `frobnicator.frobnicate()` blows up at runtime because its runtime type wasn't what you expected.

Oh, I agree that null is fucked.

Variables being nullable is not "as type safe as C". Please don't waste people's time with hyperbole like this.

I don't see why not?

In Java, every access of an object variable can blow up your program even though the type checker is happy. In C, every access of a pointer variable can blow up your program. This seems very similar. Neither language provides type safety.

EDIT: To be clear, Java is definitely safer than C. When Java "blows up" due to a null variable access, it throws an exception in a well-defined way. When C blows up due to a null pointer dereference, anything can happen, and if you're lucky your program terminates unconditionally. It's just that neither error is caught by the type system.

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.