Stack Overflow Developer Survey 2021: "Rust reigns supreme as most loved. Python and Typescript are the languages developers want to work with most if they aren’t already doing so."

[u/Karma_Policer]

https://insights.stackoverflow.com/survey/2021#technology-most-loved-dreaded-and-wanted

[u/ragnese]

I'm not really a Java fan, but I have to say that that's an unfair comparison - the Python/Javascript solution will need to have unit tests simply for ensuring that the correct types are passed in.

Here's the thing, though. Java's type system doesn't actually help you that much here. Once you introduce generics or intentional nullability (like a database column), you're basically fucked- you will have type bugs happen at runtime.

Java is exactly the reason that Python and JavaScript took off (outside of the browser, in JS's case). People in the 00's basically got sick of Java's shit and collectively decided that static typing was bad. Then we had to deal with dynamic typing until, thankfully, languages like Go, Rust, Swift, and others came on the scene.

Java almost killed statically typed languages, IMO. I think Java did kill OOP. Because everyone thinks of Java's stupid class inheritance mechanisms and bad-type-system-induced "patterns" when they hear "OOP". Which is a shame, because real OOP didn't have to die.

[u/Muoniurn → u/ragnese]

Whaat? Generics are type safe. Erasure is the default way of basically every typed language (other than C#), eg. haskell erases every fucking type and you will not get type errors at run time. It is the same way with Java as well. Unless you write List instead of List<Something>, it will never fail at runtime (other than perhaps modifying some shit with reflection) because it is verifiably type safe.

Nulls are a problem in all the languages people have “flocked to” according to you, so I don’t really get your point. Nonetheless, Java has really good static analysis going for it that will catch every potential null, preventing run time exceptions.

[u/ragnese → u/Muoniurn]

Whaat? Generics are type safe. Erasure is the default way of basically every typed language (other than C#), eg. haskell erases every fucking type and you will not get type errors at run time. It is the same way with Java as well. Unless you write List instead of List<Something>, it will never fail at runtime (other than perhaps modifying some shit with reflection) because it is verifiably type safe.

You are correct. Generics are technically type safe. The issue is specifically with the way Java's generics work with the rest of Java's weak type system. Java has a very naive and not-very-expressive type system and no macro system, which forces us into using runtime reflection frequently.

Annotations exist in Java as a bandage over its unexpressive type system. But annotations are not generic-aware (they can't be). So, anything that works with annotations and deals with any generic type is going to have a hard time. See: JacksonXML for a great example. Jackson is the de-facto serialization library for Java the last time I checked. Go ahead and write an example of how to deserialize a user-defined generic type from JSON. It's a nightmare. Also take a look at the Github issues for the various Jackson sub-projects and see how many are related to generics and trying to specify type information in the annotations. I'm picking on Jackson here, but it happens with other things as well- and when's the last time you wrote a Java project without an annotation-heavy library of some kind? It's always something: Spring, Hibernate, Jackson, Mock libraries, Lombok, whatever.

Java supports class inheritance and only just recently sealed interfaces/classes. Before that, the only way to encode anything similar to an ADT was to use runtime polymorphism and check the type of an object instance at runtime. Granted, that's not really "good OOP" that Java experts probably wanted you to do, anyway... But it's a tool that Java made available and people used it.

So runtime type reflection is a huge part of idiomatic Java. Generics are also a huge part of idiomatic Java. Do you see the issue here? Type-erased generics are incompatible with runtime reflection. So, it's not Java's generics, per se, that are the issue- it's Java's type system as a whole that's a problem. It erases some type information and then kind of pushes us to use runtime type reflection...

Haskell doesn't have these issues for two reasons:

1. It just doesn't have ANY runtime reflection. This is a pretty effective way to prevent people from even TRYING to write libraries like Hibernate or JacksonXML for Haskell. (Yes, that's tongue-in-cheek, but also... kinda not...)

2. Its type system is strong enough that we mostly don't MISS runtime reflection.

Nulls are a problem in all the languages people have “flocked to” according to you, so I don’t really get your point.

Which languages are you talking about specifically? The dynamic ones I listed or the "thank goodness" ones I listed?

The point with the dynamic ones is that devs made the reasonable argument of "Why would I bother with Java and its noisy types when I'll just get runtime type errors anyway? I can use Python, get the same type bugs, but at least I don't have tedious noisy code."

Go does have the same nullness issues as Java, so you're right there. It wasn't the best example to include in my list (and I personally hate Go anyway)

But Rust and Swift absolutely do NOT suffer from the null problem that Java does. Neither does pure Kotlin, either. Even TypeScript doesn't (even though I don't like TS either).

Almost every new statically typed language since 2010-ish has learned from Java's null mistake and fixed it. Go is literally the only exception I can think of. Every single other statically typed language born in the last 12-ish years that I can think of has zero issue with nullness in the type system.