That begs the immediate question: Why would anybody continue to hire Java developers?
I was thinking about that recently and two things came to mind:
* The JavaScript ecosystem is incredibly immature. You can deliver some amazingly supreme trash in this language and it will likely execute, most of the time. Nearly everybody is deathly afraid of the platform (the DOM) and requires the worlds largest frameworks merely to put text on a webpage, even though familiarity with the DOM is understanding just a few methods.
* Most Java developers are trained by schools.
After thinking through those two points I have to realize employers would rather burn money than train developers or pray and hope that with enough open source tools dependencies will compensate for the maturity gap.
I had a look at a couple of the Java benchmarks you've linked to and they are horribly written, completely disregarding stuff like OSR, forgetting about the warm up and ridden with absolutely unnecessary allocations.
Either someone did this on purpose or they have no idea how to write efficient Java code and benchmark it.
The benchmark game is always full of these things. Some people are very motivated to make their language shine on it, so it has good[1] implementations, almost everything else is bad. Really, really bad. It's best to just ignore it.
[1] With good defined as fast. Many of the implementations there are so contorted that no one in their right mind would use anything like it in production. But they are fast.
Yep. There were two implementations of whatever in Ada, but one of them failed to print the right output, so was disregarded in favor of the slower, but correct one. I fixed the implementation and now Ada is way, way faster. If I remember correctly I actually had the conversation with whoever is responsible for that website here on HN, and I posted the correct code here (via a link).
Are you asking specifically about what I had to do to fix the faster, but previously incorrect implementation? It is on HN somewhere. Other than that, there is no problem. Perhaps people who took the site too seriously may have gotten the wrong idea about the language's performance.
You answered "Yep" to someone's comment that the benchmarks game was "Really, really bad." and that didn't really seem to be the experience you described?
> Some people are very motivated to make their language shine on it, so it has good[1] implementations,
I said "Yep" as in "Yep, some people do contribute", and it has good implementations for some, while shitty ones for others, and it should not be taken way too seriously because of what he just said.
Yup, enough just to give me a little nudge towards the direction I was already leaning! If my favorite language is slow, I will not take it seriously at all. :)
Not warming up hotspot seems to be a constant in benchmarks for people comparing languages with Java. I mean, it's probably valid if your use case is a CLI tool (although, in that case an AOT compiler is clearly a better option)
Thanks for that. Jvm startup time used to be an issue which doesn't appear to exist anymore given those numbers - although as that reference said, it would still matter for something that is finished very quickly.
TIL
If I'm not mistaken the hallmark of benchmark game is to use same looking source code and see how fast it runs written in different languages. Basically, it presumes that all languages follow the same programming paradigms.
"So we accept something intermediate between chaos and rigidity — enough flex & slop & play to allow for Haskell programs that are not just mechanically translated from Fortran; enough similarity in the basic workloads & tested results."
I love how you insist on using the "vastly superior" phrase to mock something's you haven't even seen but have strong opinions about right off the bat.
Not taking the bait, anyone who can read and comprehend Java code will tell you the same. What I refer to is a standard way of approaching Java code benchmarking.
Apart from the questionable code quality of the benchmarks: JavaScript can be impressively fast in very small benchmarks, but things change very quickly with real applications.
Java has way more information, thanks to the type system, and can do a much better job with optimizations.
That begs the immediate question: Why would anybody continue to hire Java developers?
I was thinking about that recently and two things came to mind:
* The JavaScript ecosystem is incredibly immature. You can deliver some amazingly supreme trash in this language and it will likely execute, most of the time. Nearly everybody is deathly afraid of the platform (the DOM) and requires the worlds largest frameworks merely to put text on a webpage, even though familiarity with the DOM is understanding just a few methods.
* Most Java developers are trained by schools.
After thinking through those two points I have to realize employers would rather burn money than train developers or pray and hope that with enough open source tools dependencies will compensate for the maturity gap.