> Nothing but dirty FUD by someone whose Java skills are at best Junior level.

Lamire (the author of the blog post) is well know as the author of https://github.com/RoaringBitmap/RoaringBitmap which is in widespread use.

I love Lamire's blog posts and think he's brilliant, but I'd have to agree with the GP (though more gently) that this really does read like a list of "Things to Watch out for: My First 6 month of Java".

I suspect that weirdness has less to do with Lamire, but the weird expectations that it tries to "debunk".

Like no ones out here arguing that Java is some especially safe, super high validation language. Sure it's memory safety was a huge breath of fresh air compared to C/C++, but it's not in the same vein of reputation as an Eiffel or Ada or even Rust.

Perhaps the intent was seeing what crazy HN thread would be started :) My reading of the last paragraph was that there is no safe language since in the end it's always up to the programmer.

Well, I did have to debug a Rust program with valgrind/miri so it is not like safety is a singular axis (not shitting on Rust, I really like the language, but it is a low level language exposing low-level constructs thus low-level bugs can rear their ugly heads)

A safe language isn't a language that lets you do things safely, it's a language that will not let you do them unsafely, or will at least make it hard to do so.

The moment you allow things that don't work well with the prover, people will use them, and the whole ecosystem becomes unsafe. And by extension, your code becomes unsafe, if the compiler can't reason about what happens when your code calls theirs.

Plus, unless you have just the right linter set up, you can still accidentally mess up and do something unsafe if the compiler lets you.

When we call a language “safe”, that formally means that there’s a proof that no well-formed program in the language can do something undefined.

Java is completely safe by that definition. Now, you can have the seat-belt even tighter than that for various types of <domain> safe, but we are moving the goal-posts of the definition.

>...or will at least make it hard to do so.

Also known as the pits of success.

Null pointer exceptions by far the most frequent exception I encounter. Not only on the development side, but also as a user.

Optional is convention based and @NonNull just throws the runtime exception at a better location, so in my experience neither come remotely close to providing null safety.

@NonNull and similar annotations can and are used by static analyzer programs to completely eliminate null exceptions. For example Checker Framework can do that and much more.

This is the exact same thing that languages with null-safety have “in-built”. Sure, language support is nice, but it is here and is working

>> Java allows data races

> It does not, ... If you struggle with data races in Java

How can one struggle with data races if it does not allow it.

A lot of "I know better than standard library authors" custom code to do things that already exist elsewhere, basically.

I've seen what GP was referring to in practice.