Comment by pron
9 hours ago
A hoarder may have much more furniture than I do, but if I buy a sofa it doesn't mean I'm trying to catch up to the hoarder (who has five). Java isn't trying to catch up for the simple reason that we don't want it to have all the features Kotlin does; in fact, we're trying very hard to avoid that (not to mention that we have yet to adopt a single Kotlin feature; our features usually take a different form, even though Kotlin, Java, and many other languages often rely on the same inspiration, which is usually the ML language). That's because some languages aim to be feature-rich while others aim to be more minimal. Both are likely to accumulate features over time, but at very different rates (we'll hold off on features for years until we're satisfied that their value justifies the added complexity to the language, as keeping that relatively low is very important to us).
If you like a richer language, the Java platform offers you options, but many people prefer smaller languages (the number of Java Platform developers who use the Java language has remained pretty much at a constant ~90% for the past 15 or more years), but we're aware that a non-tiny minority of developers prefer richer languages, and so we accommodate them, too. Either way, 95% of the JDK is runtime (standard library and the JVM) and tooling, and you'll enjoy it regardless of which frontend language you prefer.
The analogy is very sensible, but I would like to add that Kotlin isn't really hoardning features in the same way Scala did.
Compared to Scala, C++, or even Typescript and C#, Kotlin feels a like a well thought out minimal modern language (as minimal as you can be, while still providing conviniences that we have grown to expect like nullability checks, or data classes).
(*Except coroutines, I feel like Java is achieving that goal waaay better with virtual threads and structured concurrency than Kotlin did with "forever experimental" API that is full of footguns and lacks any observability.)
Kotlin is absolutely massive, and they often add n small features instead of a single more complicated one, so I don't think the comparision to Scala fits.
Funnily enough kotlin added some rushed, delivered syntax sugar in the form of `when` and java just came and added proper pattern matching with algebraic data types and exhaustiveness checking into the platform itself, making it better than the guest language at its own game. Meanwhile I never felt this "landing page growing" mindset with Scala.
This is subjective of course but for me Kotlin is certainly not minimal - I'd put it closer to C# than Java in terms of features. Typescript and Java feel like far smaller languages. Of course, C++ is in a class of its own in terms of anti-minimalism.
I find Kotlin to be full footguns in general, letting you do stuff because 'why the hell not'. It feels like the Kotlin designers just wanted to show off, without considering that many of the resulting code patterns would be terrible.
> Both are likely to accumulate features over time, but at very different rates (we'll hold off on features for years until we're satisfied that their value justifies the added complexity to the language, as keeping that relatively low is very important to us).
This strategy will still navigate Java into a random local optimum like it happened with other languages (that value backward compatibility), just more slowly. The greedy algorithm does that. Even if you do it slowly and you are extra careful that each step indeed betters the language.
Everything comes to an end eventually, and there's no strategy to avoiding it. But not trying to adapt to real changes in the environment could certainly be a recipe to hasten that end. And yes, we do really try and make sure that any change we make is more than worth it.
But if in 2026 Java is the third or second most popular language in the world overall and the #1 choice for large applications that are performance-sensitive and/or need to be maintainable, but is it possible that in 20 years, despite our best efforts, Java will decline sharply, perhaps even to the point of being only as popular as, say, Go is today? Sure.
Of course, invoking 'there are two kinds of languages: one that people complain about and one that nobody uses', there are two kinds of language designs: one that is perfectly consistent and one that has had contact with the real world.
The issue is that it's hard to predict how certain features will be misused and even harder to remove a harmful feature from a language. That's why Java goes slow. (Although I think there's too much pussyfooting around string interpolation. But I also think too much type inference makes the code harder to read.)
Not always. See PostgreSQL as a counter example.
You're driving java feature set with great expertise. It is hard to complain about it.
I know it is not a technically marvelous thing, it's not a high priority either...but the only thing I'd want differently is lot more syntactic sugar that reduces common boilerplates/actions/patterns to simple one liners.
However, with AI writing most of the code now, I now doubt the importance.
> A hoarder may have much more furniture than I do, but if I buy a sofa it doesn't mean I'm trying to catch up to the hoarder
A few years back the same argument was phrased as "we don't adopt features from lesser languages" or something to that effect. Since then Java has been busy adopting those features at an accelerated pace.
> If you like a richer language, the Java platform offers you options, but many people prefer smaller languages
And Java is no longer a smaller language. Because artificial purity for misguided reasons hurts the language. And thankfully most people in Java have finally realized it.
> A few years back the same argument was phrased as "we don't adopt features from lesser languages" or something to that effect. Since then Java has been busy adopting those features at an accelerated pace.
Except it wasn't, because adopting ML features, especially lambdas and generics, were discussed in the Java team even before Java was released.
Also, the "accelerated pace" is only compared to a dry spell where development stagnated not by choice but by Sun's problems. We had a pace we liked, then we were forced to slow down, and now we're back to the pace we like again.
Also, it has always been a stated strategy to focus on innovation more in the runtime than in the language (Gosling called it "a wolf in sheep's clothing"). Java has always aimed to innovate in compiler technology, garbage collection, and telemetry as fast as it could, and we innovate faster than most in these areas.
> And Java is no longer a smaller language.
No longer smaller than what? We aim to keep the language relatively small, i.e. smaller than mainstream languages that are more eager to add features. So Java is bigger than Go, but it's smaller than C# or Kotlin or Rust, and is roughly comparable to TS or Swift in its "size".
> Except it wasn't, because
Except it was. It was you saying this. [1]
And yes, those ML features, and many other features, were adopted by other languages, and faster, than Java. Now you're suddenly saying "we're aware that a non-tiny minority of developers prefer richer languages, and so we accommodate them, too" and "oh yes, we've been thinking of these features since 1991".
> No longer smaller than what?
Than whatever your ever-changing definition is. Java, thankfully, is no longer a small/smaller language, and is rapidly adopting actual useful features, including those from lesser products.
Unfortunately it may be held back by people still thinking that a language should not be useful in any way, shape or form. Thankfully, you're being dragged into modern world kicking and screaming. Maybe in 10 more years Java will catch up with the rest of the world (as I said, it's been catching up quite rapidly).
---
[1] https://news.ycombinator.com/item?id=28985688
"our goal isn't to adopt the strategy of less successful products, but to forge our own"
3 replies →
> not to mention that we have yet to adopt a single Kotlin feature; our features usually take a different form, even though Kotlin, Java, and many other languages often rely on the same inspiration, which is usually the ML language
This seems disingenuous at best, or it's a symptom that I've noticed as a user more often that your JDK team seems to have blinders on and dismisses/ignores most other languages even if feature have proven themselves 10 times over.
There's several features Java added or is trying to add, usually 5-10+ years later than Kotlin, and that's ignoring Scala:
* Local type inference
* Switch expressions
* Records, although I found them barely usable because there is no copy() method or with-ers
* String templates unsuccessfully
* A very stripped down version of smart-casting with switch pattern matching
I'm sure there's tech-debt and esoteric compatibility concerns which make evolving Java hard, but from a developer's perspective it's just glacial to evolve and the result is weaksauce.
Local type inference, records, and switch expressions (alongside lambdas and generics) are all ML features, as every language designer will tell you (and Java did them quite differently from Kotlin). All of them, by the way, were well known to Java's original designer in the nineties, it's just that they thought it will be a while until mainstream programmers are ready for them, so their adoption in Java is best postponed.
BTW, even if you're not aware of ML's extraordinary influence on most programming languages, surely you're aware there are competitors to Java with analogous features that are far bigger than Kotlin.
As for string templates, our intent is not to have a feature simiar to what Kotlin offers. We obviously look at all languages regardless of popularity, but in that case, as we did in the case of virtual threads or records, we'll probably say, no, that's not what we want, to Kotlin's approach (even the Preview that we pulled was nothing like Kotlin's approach).
> I'm sure there's tech-debt and esoteric compatibility concerns which make evolving Java hard
Backward compatibility is rarely a hindrance at all. People just talk about it a lot because most organisations consistently say that backward compatibility is much more important to them than any language feature, but it's not all that hard to maintain.
> but from a developer's perspective it's just glacial to evolve and the result is weaksauce.
I find that statement hard to reconcile with the fact that the only languages as popular as Java or more are JS/TS and Python, while all the languages that are not "weaksauce" from "a developer's perspective" are doing far, far worse than Java. There has never, ever, been any sort of consensus among developers on the right set of features, and there have always been developers who prefer more features and those who prefer less. It's perfectly fine to be on one side or the other or even to say, "yes, I'm in the minority, but I still think I'm right", but I find it strange to claim to represent "the developer's perspective" when your preferences are mostly associated with languages that are doing worse rather than better.
I get your point, but Kotlin is still what made many of these specific features widely known to java developers, and accelerated the push from devs to get similar things into java.
Mind you, I like that java has taken its time to get the features right. Of course, java has had the advantage of enhancing the jvm while adding the features, where Kotlin had to work around the jvm in some cases (like green threads vs coroutines).
So I prefer javas version of many of the of the more modern things (but do miss Kotlin's lambdas and vast library of extension functions when writing java). But I feel it's wrong to downplay Kotlin's role in modernizing things on the jvm. Heck, if it weren't for kotlin as a temporary stopgap, I'd probably would've left the jvm while the features were still lacking in java.
4 replies →
[flagged]
>I'm sure there's tech-debt and esoteric compatibility concerns which make evolving Java hard, but from a developer's perspective it's just glacial to evolve and the result is weaksauce.
This used to be the case a few years ago. But not anymore. Java is evolving very rapidly compared to those years.