I am a big functional programming geek. I am one of the few people on the planet who can honestly say I have been paid to write F#, Haskell, Clojure, and Erlang. I have spoken at FP conferences like six or seven times, and I have shit on Java for most of my career.
And yet, my latest talk at Lambda Days basically boiled down to “Java 21 and later don’t actually suck anymore”, and I genuinely do mean that.
Java 21 is actually fun to write, even for a grumpy FP advocate like me. Virtual threads make concurrency a lot simpler, and now that there’s proper records and ADTs (in the form of sealed interfaces), along with pattern matching, the language is actually pleasant to use. I haven’t dived into 25 yet, but I suspect I will like it as much or more than 21.
The biggest issue, though, is that Java programmers won’t use the new features. It was like pulling teeth at my last job to get people to use stuff from Java 8 (e.g. the `var` keyword), and none of my coworkers even knew how to use NIO or BlockingQueues which I think predate agriculture. I mean, hell, I had explain what “fairness” was to engineers when using a ReentrantLock because someone “corrected” my code with `synchronized`.
I don’t think Java makes people into bad programmers, but I do think it selection-biases for intellectually unambitious engineers. They learn exactly enough Java in college to pass their courses, and then get a job at a BigCo that doesn’t strictly require ever learning anything more than what they were taught in their “intro to data structures” course.
I have met some extremely intelligent Java engineers who do have intellectual curiosity, so I am not saying it affects everyone, but I do think that they are the minority. Java 25 might add every feature to make my wildest dream come true but it won’t matter if I am not allowed to use it.
I can't see why you'd pick Java over C#. IMO its basically all the same preferences with slightly more consistent syntax choices. That said, Java is great too. It's underrated considering what a workhorse it is.
> The language itself is quite beautiful when used properly and with modern features.
I respect your opinion but I wouldn't call Java beautiful (of course it depends on your definition of beautiful). It takes so much ceremony to do things you would do without any thought in other languages .
Initiating a mutable set
Python
`a = {1,2}`
What most Java programmers do
```
var a = new HashSet<>();
a.add(1);
a.add(2);
```
Shorter one but requires more ceremony, and hence knowledge of more language semantics
```
var a = new HashSet<>(new Arraylist<>(List.of(1,2))
```
I don't know if the above works but the Idea is to initiate a list and pass it into a HashSet constructor.
Similarly Java 21 allows you to model union types but doing so requires you to define N+1 classes where N is the number of union cases whereas in other languages it's as simple as `type A = C |D`
> The language itself is quite beautiful when used properly and with modern features.
> It just really needs a makeover and better tools.
I love java, wouldn't call it beautiful though. But I don't need a language to be beautiful, I need it to be pragmatic, blisteringly fast, have an extensive ecosystem and top quality tooling. Java delivers #1 on all of those so I love it.
For beauty, I like ruby and lisp, but those both fail on all the other criteria so they are mostly for hobby use for me. (Python, the darling of everyone these days, is pretty much dead last on every criteria except popularity.)
> better tools
I'd say Java & JVM has pretty much the best tooling on all fronts.
I can't think of anything that has better tooling around the language and runtime.
i would prefer it, if they improve and extend the java standard library and the tooling for libraries
many people will tell you that the standard library is not as performant as it could be and does not have as many batteries as python and try managing your dependencies...
that would be far more important than the next super duper feature IMHO.
I’ve worked in Java for over 20 years. Being the “lingua franca” of the enterprise is its biggest strength IMO, but it is also perplexing to me that it was able to do that in the first place. The language itself is not bad. The tooling around it is very good. But the codebases you encounter written in it, particularly in the enterprise, are often horrible.
The explanation on why Java lets you use unnamed variables to prevent accidental use during deconstruction, but those unusuable variables still getting initialized by calling accessors, is a perfect example why I dislike the way Java implements improvements.
Every single, logical step that led to this hidden performance problem makes complete sense, because every improvement had to be its own tiny, contained improvement, but the end result is that `case Foo(int _, String _, User _, int age)` will still call three getters _just in case_ you're abusing the language to add side effects to accessors.
Perhaps even worse is the explanation that follows: if you don't mess up your accessors, the JVM _may_ decide to not call those accessors at runtime. So now the language itself has this weird performance impact to maintain backwards compatibility, but at runtime that backwards compatibility _may_ not exist and provide you with a performance improvement instead, negating the whole reason why backwards compatibility was added in the first place.
I like the improvements to Java, don't get me wrong. It's no longer the JDK 1.7 language poor enterprise programmers are stuck with. But if the Java people had come together and worked this out as one single feature, rather than five different ones, we wouldn't have needed to remember edge cases/a code analysis tool to remind us that using this intuitive language feature _may_ actually has a 3x performance impact depending on the mood the JVM is in today.
17 comments
[ 4.1 ms ] story [ 84.0 ms ] threadAnd yet, my latest talk at Lambda Days basically boiled down to “Java 21 and later don’t actually suck anymore”, and I genuinely do mean that.
Java 21 is actually fun to write, even for a grumpy FP advocate like me. Virtual threads make concurrency a lot simpler, and now that there’s proper records and ADTs (in the form of sealed interfaces), along with pattern matching, the language is actually pleasant to use. I haven’t dived into 25 yet, but I suspect I will like it as much or more than 21.
The biggest issue, though, is that Java programmers won’t use the new features. It was like pulling teeth at my last job to get people to use stuff from Java 8 (e.g. the `var` keyword), and none of my coworkers even knew how to use NIO or BlockingQueues which I think predate agriculture. I mean, hell, I had explain what “fairness” was to engineers when using a ReentrantLock because someone “corrected” my code with `synchronized`.
I don’t think Java makes people into bad programmers, but I do think it selection-biases for intellectually unambitious engineers. They learn exactly enough Java in college to pass their courses, and then get a job at a BigCo that doesn’t strictly require ever learning anything more than what they were taught in their “intro to data structures” course.
I have met some extremely intelligent Java engineers who do have intellectual curiosity, so I am not saying it affects everyone, but I do think that they are the minority. Java 25 might add every feature to make my wildest dream come true but it won’t matter if I am not allowed to use it.
There were times I hated it, but turns out I really just hated messy, over-engineered legacy code and working in a gray cubicle at aging MegaCorps.
The language itself is quite beautiful when used properly and with modern features.
It just really needs a makeover and better tools.
I respect your opinion but I wouldn't call Java beautiful (of course it depends on your definition of beautiful). It takes so much ceremony to do things you would do without any thought in other languages .
Initiating a mutable set
Python
`a = {1,2}`
What most Java programmers do
``` var a = new HashSet<>(); a.add(1); a.add(2); ```
Shorter one but requires more ceremony, and hence knowledge of more language semantics
``` var a = new HashSet<>(new Arraylist<>(List.of(1,2)) ```
I don't know if the above works but the Idea is to initiate a list and pass it into a HashSet constructor.
Similarly Java 21 allows you to model union types but doing so requires you to define N+1 classes where N is the number of union cases whereas in other languages it's as simple as `type A = C |D`
> It just really needs a makeover and better tools.
I love java, wouldn't call it beautiful though. But I don't need a language to be beautiful, I need it to be pragmatic, blisteringly fast, have an extensive ecosystem and top quality tooling. Java delivers #1 on all of those so I love it.
For beauty, I like ruby and lisp, but those both fail on all the other criteria so they are mostly for hobby use for me. (Python, the darling of everyone these days, is pretty much dead last on every criteria except popularity.)
> better tools
I'd say Java & JVM has pretty much the best tooling on all fronts.
I can't think of anything that has better tooling around the language and runtime.
many people will tell you that the standard library is not as performant as it could be and does not have as many batteries as python and try managing your dependencies...
that would be far more important than the next super duper feature IMHO.
Every single, logical step that led to this hidden performance problem makes complete sense, because every improvement had to be its own tiny, contained improvement, but the end result is that `case Foo(int _, String _, User _, int age)` will still call three getters _just in case_ you're abusing the language to add side effects to accessors.
Perhaps even worse is the explanation that follows: if you don't mess up your accessors, the JVM _may_ decide to not call those accessors at runtime. So now the language itself has this weird performance impact to maintain backwards compatibility, but at runtime that backwards compatibility _may_ not exist and provide you with a performance improvement instead, negating the whole reason why backwards compatibility was added in the first place.
I like the improvements to Java, don't get me wrong. It's no longer the JDK 1.7 language poor enterprise programmers are stuck with. But if the Java people had come together and worked this out as one single feature, rather than five different ones, we wouldn't have needed to remember edge cases/a code analysis tool to remind us that using this intuitive language feature _may_ actually has a 3x performance impact depending on the mood the JVM is in today.