That's like a compulsive hoarder seeing a guy buying a lawn chair and saying, oh, nice to see you finally catching up!

That the Java language is slow to evolve while the Java platform evolves quickly has been one of the central strategies of Java since inception. In fact, James Gosling wrote back in 1997 how Java should only adopt language features loooong after they've been tried in other languages. It's worked very, very well. There's obviously a portion of users (<10%) who prefer a faster-moving, feature-rich language, and they have good options on the Java platform, but the Java language philosophy has been more attractive to a much larger group of developers.

What is more interesting is not which features Java has chosen to adopt, but which ones it hasn't and won't: yes to lightweight threads but no to async/await; yes to pattern-matching but no to extension methods.

What you're saying is exactly what I'm saying, except we disagree what a "better language" is. I find the approach Java has taken causes people to fetishize complexity with it. It's not so much about "my language has more features than Java therefore it's better" (the hoarder reference) it's "my language is simpler than Java therefore it achieves what Java does with less in multiple dimensions." And I don't mean Scala, either. That's just piling on more of what Java is.

> compulsive hoarder

I'm looking at Scala and C++

Can you list some of the interesting features that were not adopted in Java?

Features that Java doesn't and won't have:

Extension methods

Async/await -- Java is going with lightweight threads.

* Lambda syntax took years after it was mainstream.

* I don't think Java still has string interpolation.

* List, Map literals are not a thing Java has either.

* Value types aren't in yet.

* If as expressions. You have to use ternary.

These aren't complaints. I know what I'm getting with Java. No hate.

What's wrong with List.of(1,2,3) or Map.of("a", 1, "b", 2)?

Switch expressions can do what if expressions do.

Nothing's wrong with that or with `String.format`. I just find it less ergonomic. Like I said, no complaints anywhere. You can just as well use `ExecutorService`s instead of async/await and all that.

Your use case doesn't have to be everyone else's. As opposed to Kotlin or Scala, Java is a great choice for performance-sensitive applications because there's (almost) no syntactic sugar that produces throw-away objects and induces unnecessary memory pressure.

> (almost) no syntactic sugar that produces throw-away objects

Strings and automatic boxing come to mind.

The thing I love about Java is that they continue to improve the language without:

A) Throwing the kitchen sink in and making mistakes.

B) Changing anything that already works.

There are very few languages that continue to improve and provide such long term stability. More often than not more feature full languages end up forcing me to re-test or rewrite sections of my old code base for forwards compatibility.

The Java implementations are typically better than their counter parts. See Kotlins when vs switch expressions in Java.

Kotlin's optional implementation is much better tho. It's not a universal.

What about switch expressions in Java is better than Kotlin's when? I haven't personally used switch expressions in Java yet, but I've read the JEP and I don't see anything special or interesting.

If you want to use any language, what makes the JVM important? Just use whatever that tech stack uses. Node uses v8, for example.

The ecosystem of supporting libraries for Java is bigger than any other ecosystem. There's a mature library for every concept in existence. The Node ecosystem has a lot, but for server-side libs it still doesn't reach the coverage of Java.

Apache, for example, supports a ton of Java libraries for which there's little competition, certainly not well distributed across language ecosystems. PDFBox, Lucene, etc.

When you're in the nitty gritty of automating business processes, that sort of thing is invaluable. For CRUD-style web services, any language will do the trick.

(I say this as not a big fan of Java the language)

Python also has a similarly wide ecosystem, and does better specifically in some regions than any other language, like ML, but a different set of focus areas. It's probably the other top contender for business-process automation, but big enterprises prefer OOP/static typing for typical work.

C# probably comes close in many areas, but there's still a split between the .net core and not-core ecosystems for the long tail of libraries, and no open-source powerhouse quite like Apache in the mix.

(C/C++ might fall here somewhere too, but I don't know nearly enough about those language ecosystems to comment)

In the Node ecosystem, there's no shortage of PDF libraries, including the quite full-featured and not unnecessarily painful to use PDFKit.

We have a Lucene binding, too. It's called Elasticsearch. :)

> There's a mature library for every concept in existence

If you'll forgive a light trolling: how about ahead-of-time compilation, allocating small objects on the stack, UTF-8, compile-time asserts, or SIMD support?

(Was going to include await/async, but then I remembered EA Async.)

I realise this is a little off topic, but the JVM isn't without limitations. (Or perhaps all my examples are wrong - disproof welcome!)

AOT: GraalVM Native Image (https://www.graalvm.org/docs/reference-manual/native-image/), Project Leyden: https://mail.openjdk.java.net/pipermail/discuss/2020-April/0...

SIMD: https://openjdk.java.net/jeps/338 (to be merged soon), plus, of course, auto vectorisation, which is already in.

Allocating small objects on the stack: this already happens automatically through escape analysis, but more generally (and more importantly) arrays-of-structs: http://cr.openjdk.java.net/~briangoetz/valhalla/sov/01-backg...

UTF-8: What do you mean? Java has supported UTF-8 for a loooong long time. Even the source files support Unicode with UTF-8 encoding.

compile-time asserts: Not sure what you mean. But there's a rich compile-time plugin mechanism: https://www.baeldung.com/java-annotation-processing-builder and even pluggable type systems: https://checkerframework.org/manual/

Async/await: how about lightweight threads, instead? https://wiki.openjdk.java.net/display/loom/

You can get AOT compilation with GraalVM today, allocating small objects on the stack is being worked on in Project Valhalla, compile time asserts can be implemented with annotations if you care (see @NotNull), utf-8 is available in the standard library in the StandardCharsets class.

For Async/await, I believe a much better approach is available with Quasar today or with Project Loom soon.

SIMD is an issue though if you need that.

SIMD is being worked on as well: https://openjdk.java.net/jeps/338

See Project Panama for the encompassing project: https://openjdk.java.net/projects/panama/

AOT was available for over a DECADE with the GNU Compiler for Java before it was removed.

It's also long been possible with lesser-known proprietary solutions like Excelsior JET, so I suppose Java can claim to have a mature solution to that feature, just not a mature mainstream FOSS solution (not counting Graal).

The JVM world has Graal for AoT, FWIW. I would argue that await/async is really settling for the mediocre still. Many languages, even JVM languages offer more powerful abstractions and concepts for solving that problem. Clojure's implementation comes to mind.

Yeah, I'm thinking higher level, for sure, rather than limitations of the language - fair to call out.

You can specify UTF-8 as the default charset (unless you mean for identifiers?) and Grall does exist for AOT.

I thought Java's String was hard-coded to UTF-16. Is that mistaken?

I don't think you can compare V8 with the JVM. For starters, last time I checked, V8 is still single threaded, isn't it? Also it seems like future versions of JS are embracing things that make it look like they're envying Java, which seems like it's going in the wrong direction.

You can do parallel computing in Node and the browser using workers. Also what features do you mean that "envy Java"?

Compared to any language that has threads, workers are a usability nightmare and come with a million caveats.

(For example they have major limitations in Electron, which is one place where having threads would be very convenient. The current best practice is to spin up an entire new hidden browserwindow instead which is frankly insane.)

We offload anything that would need a thread to another process on the JVM for electron. I know a few other projects offload to a GO process.

workers are clunky compared to how parallel/async computing is implemented in Clojure, for example.

static typing seems to be on the horizon (facepalm)

Well yeah, Microsoft developed TypeScript to resemble C#'s type system so naturally it will look a bit like Java? TS is far from being the de-facto standard though (maybe because it's centred around OOP?)

I'm not an expert on this subjectrobably the best thing the JVM has going for it is two things: many world class extremely tunable garbage collectors and acres of software written for it already. V8 has tons of software written for it but the focus is somewhat different (see Apache projects)

I'm not sure they meant any language. It sounds like they're advocating for using a non-Java language that compiles to bytecode to be run on the JVM. E.g. Kotlin, Scala, Clojure, Groovy, Jython, JRuby etc.

The goal of the JVM is "write once, run anywhere". v8 achieves the same, but for languages that compile to Javascript. E.g. Dart, Elm, Typescript, CoffeeScript, ClojureScript etc.

I think the real choice to be made is ecosystem. There are languages to suit every programming style in either camp. The availability and quality of packages in the Java ecosystem is higher IMO (use Spring and it just works).

Node has non-blocking I/O by default; it's possible to implement the same in Java, but you have to make a conscious decision to do so. Java has threads, but Node has workers. Java can have a longer startup time and is better suited for servers with high uptime, Node starts up quick and is easier to use in on demand situations etc.

I don't really know why you would, but there is RingoJS if you want to run Javascript on the JVM for some reason.

It has an unmatched combination of stability, productivity, performance, observability and ecosystem size. There are few if any platforms that offer. E.g. very few platforms, if any, offer the kind of low-overhead, always-on, in-production deep profiling that Java has [1], certainly not platforms with similar performance.

[1]: https://blogs.oracle.com/javamagazine/java-flight-recorder-a...