> but its actually 5-10x slower than Java and uses 5-10X more memory

I am definitely against the "Java is slow" claims and think they are mostly rediculous but so is this claim.

Saying "uses 5-10x more memory and 5-10x slower" goes against every benchmark I've ever run and my understanding.

Mostly because JavaScript runs on several JITs (V8, JavaScriptCore, SpiderMonkey, Chakra) with different performance goals and characteristics and so does Java (which runs very differently with Art compared to HotSpot for example). Not to mention things like Graal :)

Slowness isn't a property of the language it's a property of the runtime. Usually performance is dominated by things like the speed of the packages used and standard library and not even the compiler.

There is no 5-10x factor _either way_ between JavaScript and Java VMs, not to mention you can run JavaScript on the Java VM anyway so that comparison doesn't hold in that regard either.

>Slowness isn't a property of the language it's a property of the runtime

This is true to an extent, but look at the time and money poured into PHP and how slow it still is after all these years.

Language design choices have a huge effect on how fast the runtime can be. In Javascript, objects are stored as a map of key->value pairs, and aren't strongly typed. This design requires more overhead for type checking and many optimizations used by strongly typed languages won't work. Even in toy benchmarks its clear that Java has a performance lead https://benchmarksgame-team.pages.debian.net/benchmarksgame/... . It's slower than java on every test.

You don't see the memory difference because these toy benchmarks don't allocate much. Node/JS will always use more memory for storing objects, sometimes far more because it isn't strongly typed. In Java, an array of ints will use 32 bits * size plus some fixed bytes. In Javascript, each item in the array can use 2-3x the max "size" of the number, because the runtime can't figure out what type it should be.

> You don't see the memory difference

You'll see the memory difference if you compare Java with C++: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Except for one benchmark, where memory requirements are likely determined by the implemented algorithm, Java consumes in order of magnitude more memory across the board.

> … Java consumes in order of magnitude more memory…

Not for reverse-complement.

Not for k-nucleotide.

Not for binary-trees.

Not for mandelbrot.

Not for regex-redux.

The others show the default JVM memory allocation mas o menos.

Other benchmarks from the same group do show the memory usage and both node and Java are quite bad, as expected. Node is spectacularly bad at some, using 1.8 GB vs Java's 384M or C++'s 155M for example.

Java's usage will never compare to compiled languages without GC because it has to cache a bunch of code in RAM and the garbage builds up between collection cycles. It's pretty bad compared to something like C for sure :)

Depends how well they end up implementing value types.

System programing languages int the 90's with GC faired pretty well in this area.

Naturally they had much more control over GC, how value types were handled and manually allocation on unsafe modules.

> This is true to an extent, but look at the time and money poured into PHP and how slow it still is after all these years.

PHP7 isn't a slow language at all - it's much faster than previous versions actually. There are servers like aerys [1] that easily handle 10,000 concurrent requests on reasonable hardware. The reason sapi (read "regular") PHP isn't "faster" is because caching and the ease of deploying more servers makes it less of a priority to stakeholders.

Like I said - this is more dependent on the libraries used than the language.

> In Javascript, objects are stored as a map of key->value pairs, and aren't strongly typed.

This is also not true - JavaScript objects are stored through a technique called "hidden classes" akin to a C like struct in most modern runtimes [2].

> This design requires more overhead for type checking and many optimizations used by strongly typed languages won't work.

This is also false, JIT engines store run time information about the object (see hidden classes above [2]) and use that to optimize by type. V8 does this a lot and monomorphic functions are much faster [3]. Inline caches (ICs) really help there.

> It's slower than java on every test.

All those programs are poorly written and are running outdated versions of both Java and Node.js. Moreover they do not represent a workload people have in any reasonable way. I think that regardless it is possible Java is faster in a lot of workloads. I wouldn't use Java nor Node.js for any of the above programs there.

> Node/JS will always use more memory for storing objects, sometimes far more because it isn't strongly typed.

See [2] and [3] - that's not how it works.

> In Java, an array of ints will use 32 bits * size plus some fixed bytes. In Javascript, each item in the array can use 2-3x the max "size" of the number, because the runtime can't figure out what type it should be.

V8 has explicit handling for arrays of SMIs (small integers) with bailout semantics. JavaScript runtimes figure this out - feel free to ask for V8 source references. Also see my answer here on a library I maintain (bluebird) https://stackoverflow.com/a/24989927/1348195

[1] https://github.com/amphp/aerys [2] https://richardartoul.github.io/jekyll/update/2015/04/26/hid... [3] https://mrale.ph/blog/2015/01/11/whats-up-with-monomorphism....

A lot of Javascript's optimizations are fragile, as in they don't always hold true, so there's overhead determining if the assumptions still apply.

For instance, Javascript's hidden class optimizations are disabled as soon as someone "breaks" the assumption by doing something like accessing a variable using a dynamic array index rather than dot notation.

Javascript runtimes also try to infer types as you say based on how objects are used, but this is also a fragile optimization. For instance, if you use an assumed "int" in a string-like way the runtime re-assigns the tagged type. And it's hard to know whether you (or the library you're using) does so.

Those programs might not represent a real workload but TechEmpower's framework benchmarks are closer. https://www.techempower.com/benchmarks/#section=data-r16&hw=...

On most of those benchmarks the fastest JS framework is ~5X slower than the fastest Java framework.

And yeah the array optimizations are related to what we both mentioned above, but again the optimization is not durable. It only works sometimes, and incurs its own overhead.

> For instance, Javascript's hidden class optimizations are disabled as soon as someone "breaks" the assumption by doing something like accessing a variable using a dynamic array index rather than dot notation.

This is definitely not true.

> For instance, if you use an assumed "int" in a string-like way the runtime re-assigns the tagged type. And it's hard to know whether you (or the library you're using) does so.

Also not true - if you assign an integer to a string the engine will still use optimized code - the caveat is different and in megamorphic functions - if your function can accept lots of types that's problematic.

> On most of those benchmarks the fastest JS framework is ~5X slower than the fastest Java framework.

All of those benchmarks are dependent on the underlying library and not the language at all.

> And yeah the array optimizations are related to what we both mentioned above, but again the optimization is not durable. It only works sometimes, and incurs its own overhead.

That's not really how a JIT works and Java is also a JITd language on some runtimes (and the same person wrote both JITs originally - Lars Bak). The overhead is constant and low for the optimizations. The Java JIT compiler does a ton of such assumptions and bailouts as well to elide creating and allocating objects.

> and are running outdated versions of both Java and Node.js

That does not seem to be true —

java version "10.0.1" 2018-04-17 versus "Java SE 10.0.1 is the latest feature release for the Java SE Platform"

http://www.oracle.com/technetwork/java/javase/downloads/inde...

— or not-very out-of-date —

Node js v10.5.0 versus 10.6.0 Current

https://nodejs.org

> All those programs are poorly written…

Please contribute your own much better written programs —

https://salsa.debian.org/benchmarksgame-team/benchmarksgame/...

Hmm. Just checked memory use on some services we run on Go, Node, and Java. I'm not part of the Java team but results:

Go: 40M Node: 64M Java: 4GB

Any Java service I've seen in production has similar numbers. Coupled with the incredible startup time it's hard for me to see why you'd pick it in 2018.

>Go: 40M Node: 64M Java: 4GB

This benchmark is completely useless unless you have 3 identical servers with identical algorithms using identical API and models with identical work load. so... why would you waste time writing them?

Also, these [1] benchmarks which are more reliable, because we know what servers they're run on and we can inspect source code, unless, of source, you can prove your statement.

[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

If you tell your Java application server "here you have 4GB, use it as you wish" it will happily comply and trade memory for performance.

In most of the cases it's just a matter of setting a few Java runtime startup parameters.

It's disrespectful to take 4GB if you don't need it. This should never be the default...

It's the default because in any garbage collected language you can delay taking out the trash as long as you want... as long as you have memory. The most efficient thing to do is never run the collector at all.

JS does frequent GC cycles because its unacceptable to let a webpage eat all the ram. Not sure why Go collects so frequently. Java's default IMO is the most reasonable of the three. If you have a server with 4gb the best choice is to let the garbage collector use all of it

Read the comment again:

> If you tell your Java application server "here you have 4GB, use it as you wish"

JVM uses as much memory as you allow. Use `-Xmx39m` to beat Golang.

My guess is that it won’t work with less than 1GB bc of spring boot, hibernate and all the rest of Java enterprise “microservice” goodness.

IMO almost nobody is writing microservices with spring boot because its so gigantic. Hibernate isn't bad on memory use on its own.

There's a raft of more sane choices these days like Play, Dropwizard, Vert.X etc.. They all use far less resources. Spring Boot is huge because it has to support a decade of obsolete junk, its far more than just a REST app framework.

Checkout TechEmpower's framework benchmarks https://www.techempower.com/benchmarks/#section=data-r16&hw=...

(I added filters to limit to Java+Go+JS+Python and limited DB to Postgres and Mysql)

Java and Golang lead the pack, with JS a distant second and most Python frameworks hanging out near the bottom

>IMO almost nobody is writing microservices with spring boot because its so gigantic.

I've encountered plenty of spring boot microservices in my work and, from what I hear of other companies, it's not particularly rare.

Most of the time, if you have a team that's productive in Spring, a manager or lead will be happy to spend some extra memory and get more features shipped.

> My guess

So you actually haven't tried to run an application with those libraries, and you don't even know what libraries that particular application is using, and here you are speculating about something you don't know and/or understand.

I've used Spring and he's probably right :) . But there's better choices these days. Any Spring micro-services out there are probably by a team that knew Spring well and didn't want to learn a more suitable framework

Whats different about the equivalent libraries in other languages?

Spring is huge... The closest competitor might be Rails

Yeah, but they all seem to need high mem amounts or they OOMException.

Well, it may also be a bad code written by amateurs which use memory inefficiently.

Also, https://github.com/cxxr/better-java with recommendations for learning how to write modern Java.

While the gist of that page is nice, there are many many flaws with it. I could enumerate them all, but suffice to say don't just take the author's word for using Optional parameters or always prefer Guava immutable collections or any of that. Much of it is wrong or at least debatable.

Nice! I think it may be slightly out of date though. For example, you don't need Tuples library if you use Apache commons because it has Tuple support. Also, Javaslang has been renamed Vavr. Still a solid article though

How efficiently does Java run when compiled to the browser platform? (e.g. WASM)

(The browser is an important target these days, so imho this question must be addressed; besides, I want to be able to use the same code on the server as on the client; and sadly, the JVM isn't guaranteed to work in every browser).

I'm really excited for WASM, it should be nearly as fast as native code. Java and native code aren't far apart though, so I would say 1.5-2x faster generally

Ok, but I'm worried about the garbage collector, and if it can run concurrently without interrupting the program (as a native JVM would do it).

It should be able to... Hopefully Go and Java will be some of the first GC languages to target WASM, and we'll find out :) . Personally I'm more worried about the size of the GC getting added to the binaries than how fast it is.

AssemblyScript already does it, if I am not mistaken.

If the Javascript garbage collecter can do it then I don't see why not.

The JS GC can run in native code, in a separate native thread with shared memory access, and it can use things like memory barrier instructions, which have no equivalent in WASM yet.