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...