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.)
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.
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.
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.
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.
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.
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 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"
I said "strategy" not "feature". That adopting a feature that a less successful language had invented or adopted is not the same as adopting the strategy of a less successful language was precisely my point about buying a sofa not being the same as "catching up" to a hoarder.
I said "we shouldn't be a hoarder", not "we shouldn't get a sofa".
> 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".
But Java started adopting ML features over twenty years ago. Where do you think we got generics from? The discussion about lambdas and generics between Gosling and Joy, even predating Java's release are Java lore (https://archive.computerhistory.org/resources/access/text/20...).
> 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.
My definition isn't ever-changing, it's just relative. Being a relatively small language means, at the same time, not adopting the strategy of richer languages and adding select features but at a slower pace. This was Gosling's "a wolf in sheep's clothing" strategy since the very start: a very innovative, fast-moving runtime (where most of the benefits to the software's end user are hidden) wrapped in a non-threatening, conservative language. Conservative doesn't mean frozen and relatively small doesn't mean never-growing, but they do mean not adopting relatively rich fast-changing language strategy either. Our strategy has worked well for us, and yes, I still think it's silly to suggest we should change it because languages that aren't doing as well have a different strategy.
Even Java's GC and JIT came from Lisp and Smalltalk, but not the strategy (which was Gosling's point that these helpful features were part of thretening products).
Strange. Every time we talk about features and what other languages have, you always come up with "lesser languages" and "hoarders".
When Java ends up adopting those features, suddenly it's "we accommodate a non-minority number of developers" and "we've been thinking about this since before Java was released".
> My definition isn't ever-changing, it's just relative.
Yup.
> illy to suggest we should change it because languages that aren't doing as well have a different strategy.
...aaand there it is again. "The lesser languages".
Anyway. I'm glad it seems you're in the minority seeing how Java has picked up its development pace. Hopefully it will only accelerate and adopt more features for "non-minority number of developers we've been thinking since before 1991".
Adieu.
It's not those features, though! Obviously, a hoarder has everything, so anything you buy is something he has. We are adopting a small portion of the features that feature-rich languages have, which is exactly the difference between a more feature-rich language and a more minimal one.
> "The lesser languages".
I never said "lesser languages"; you said it. I said "less successful languages". You're arguing with things I haven't said, and even when you quote me, you misquote me to completely change my meaning. No one, on the Java team or outside it, considers Lisp, Smalltalk, and ML - the languages that inspired Java - "lesser" languages. They are, however, all less successful languages as a matter of fact. It is because they are not lesser but they are less successful that we selectively adopt a portion of their ideas but do not adopt their strategy.
> When Java ends up adopting those features, suddenly it's "we accommodate a non-minority number of developers" and "we've been thinking about this since before Java was released".
No, we've also been thinking about features that may well probably never make it. I'm not even sure what you're trying to say, but you should know that anyone who works in language design has been familiar with type inference, generics, typed lambdas, pattern matching, and algebraic data types at least since the late eighties because ML has been the biggest single influence on language designers and other PL fans in the past couple of decades (ML was released in the early seventies, but it didn't become so influential right away).
> I'm glad it seems you're in the minority seeing how Java has picked up its development pace.
Java has picked up its development pace compared to the time we were involuntarily stagnant due to declining investment from our corporate overlords. As always, most of the development is in the runtime, as that has always been our strategy, and we all think it's a good one. I'm very happy that we can do more now than we could fifteen years ago, but the Java language won't become a (relatively) feature-rich language, even though it will continue to add features.
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.
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.
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.
I disagree for an obvious reason: only a small minority of Java developers know Kotlin. When we want to see if the median developer is ready for some ML feature, we certainly look at other languages, but Kotlin doesn't matter beyond its size (which is not inconsiderable, but is also nowhere near the largest Java competitor that's quick to adopt features).
> 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).
And C# could have done the same as Java but instead did what Kotlin did (or, rather, Kotlin did what C# had done), and we looked at both and said: we don't want that. That's why I'm saying that the "catching up" narrative doesn't hold up to any scrutiny.
Obviously, Java has been a huge innovator in optimising compilers, garbage collection, and low-overhead telemetry — areas where it's ahead of virtually everyone else — and focusing innovation on the runtime rather than the language has been one of James Gosling's stated goals since the beginning. So catching up is also silly when talking about a technological leader.
> But I feel it's wrong to downplay Kotlin's role in modernizing things on the jvm.
I'm neither downplaying nor overplaying it. As one of the Java architects, I'm telling you what it is. And "modernising things" on the Java Platform ecosystem is quite a different thing from influencing Java language features.
When we discuss other languages, and we discuss all of them, the ones that are discussed more are either the bigger ones or the more novel ones. Kotlin has shown some novelty, especially around its design of generics and of nullability types, but these happen to be two areas where we have actually not (yet?) made changes.
> 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.
That may be true, but it's irrelevant to what we're discussing. If anything, if Kotlin had served as a significant enough stopgap for those developers who prefer richer languages, it would have helped us not to adopt certain features or to adopt them more slowly.
I'm not saying Kotlin hasn't had a positive influence on the platform and, indeed, it may have helped especially in those years when Java stagnated, but it didn't push Java toward adopting more ML features.
This is just so wrong. I don't know a single Java developer who does not know Kotlin. In fact, almost everyone is using Kotlin for most code, with Java being mostly used in legacy projects.
I know you'll answer that I am in a bubble or whatever, but it's frustrating how you think that's a valid argument you can make against me, but not me against you :D seriously. You have no idea what my experience is. I've worked in several countries so I can tell you my experience is not just local. I still like Java (and with Java 28 I am becoming hesitant to continue using only Kotlin for new projects) but anyone who cares about new features like pattern matching was already on Kotlin a long time ago.
> but anyone who cares about new features like pattern matching was already on Kotlin a long time ago.
First, that doesn't mean it's not a minority of people. And by the way, we don't base our decision on which language feature to include on the number of people who are already asking for a feature (which is always a small minority) but on the number of people we believe will be significantly helped by a feature once they learn about it. I.e. it is perfectly possible that 100% of the people who wanted pattern matching before we added it had left for Kotlin or Scala and at the same time that number amounts to only 10% of the people who enjoy the feature and benefit from it in Java. That many mainstream languages add a feature is only a signal to us that the median developer is ready for it if we decide it's a good feature to add. I've been using pattern matching since the late nineties when I first learnt ML and a bit of Haskell (Haskell was the language of the future back then), but if I were a language designer back then, I'm not sure I would have thought that it's a feature a mainstream language should have prioritised in 1998.
Second, we don't have usage telemetry in the JDK so we don't get a full picture, and instead we rely on the usual sources for this kind of information: meeting with large customers and analyst reports. If you have access to more comprehensive statistical data, then I would be interested in seeing it, but it's a well-known phenomenon that people are usually only directly exposed to information about their own circles and don't have industry-wide data. The Java ecosystem is huge, and like the situation with the software industry in general and enterprise software in particular, most Java software isn't even written by software companies.
Also, rest assured that there is still plenty of corporate drones that don't know Kotlin and couldn't care less because Java puts food on the table while providing a stable consensual development environment. Kotlin opens many doors, most of which should have better be left closed.
This used to be the case a few years ago. But not anymore. Java is evolving very rapidly compared to those years.