The biggest one first: Operationally maintaining the JVM is a nightmare. It can be fast, but that isn't guaranteed and its not trivial to find out why, and easy for developers to mess up. It uses significantly more memory than anything else which will be your largest cost driver when running large services, compute is cheap, RAM is not.
Security is probably the next biggest one. Vulnerabilities in the JVM are a problem but you'll have that in most software (given maybe only Flash beats the JVM in the history of boths existence) but the defaults for running a lot of things like groovy aren't secure (there is a debug port you can directly manipulate the memory of the running process without authentication). Commonly people use these debug ports in production, not just leave the defaults but actively choose to let them run. This is a very common pattern in Java based services usually caused by my first point. I am not aware of any other language or framework that offers remote memory access as a feature.
Then there are the dependencies and package ecosystem. I believe the "built on the JVM" languages like Kotlin have gotten a lot better at this, but as soon as you start tapping into the pure Java "enterprise grade" libraries you're most likely bringing in way more than you bargained for both in terms of complexity, maintainability, and security. A lot of those libraries are simply poorly built.
> Operationally maintaining the JVM is a nightmare
The JVM gives you practically every knob you need to achieve maximal performance for your workload. I don't know of any other environment that does that. Secondly, with new GCs like ZGC and Shenandoah, the number of knobs to tune (at least with respect to the GC) has decreased dramatically to only a couple.
> Security is probably the next biggest one. Vulnerabilities in the JVM are a problem but you'll have that in most software
This is a non-issue for backend systems. Barely anyone uses Java for browser-side rendering anymore.
> The JVM gives you practically every knob you need to achieve maximal performance for your workload. I don't know of any other environment that does that.
That's because no other environment needs to. No other environment eager loads a quarter gig of ram to say hello world. The fact that you need to know at least 16 flags for the JVM with obscure syntaxes to get a basically stable Tomcat server (not Tomcat flags, those are another nightmare) is precisely the problem with Java.
> This is a non-issue for backend systems. Barely anyone uses Java for browser-side rendering anymore
You've got to be trolling on this one. I'm definitely not talking about browser-side rendering. Weak backend systems are exactly how Fortune 500 systems get breached over and over and over. This was exactly the cause of the Equifax breach and so many others. You should never think that is ok.
> That's because no other environment needs to. No other environment eager loads a quarter gig of ram to say hello world.
This is just hyperbole and you know it. The JVM with the turn of a few knobs is able to accommodate high throughput batch workloads, as well as lower latency workloads, especially with the advent of ZGC and Shenandoah, all while supporting multi-TB heap sizes.
Look at what hacks the Discord and Twitch teams had to endure to get around golang's workload specific GC for example, and it will show why the JVM is written the way it is.
> Weak backend systems are exactly how Fortune 500 systems get breached over and over and over. This was exactly the cause of the Equifax breach and so many others. You should never think that is ok.
Those were not JVM-specific issues, and would have happened regardless in any hosting environment or even compiler if we're talking about running single binaries. You need a good upgrade path process laid out.
> The JVM gives you practically every knob you need to achieve maximal performance
While this is true, finding folks that deeply understand how those knobs work, (and what the potential pitfalls are of twisting each knob might be) is not as easy as finding a Java/Kotlin/Scala/Clojure/JRuby developer. The out-of-the-box JVM experience can take one quite a long way. It's that last mile to real performance that can be the nightmare.
Well, you need operations people and people with experience anyway. We've seen the blog posts by companies like Discord and others that needed to implement difficult workarounds in their golang code bases. The problem is always there, not thinking about it won't make it go away. I'd argue that golang "solution" was a big hack, and that having a proper mature solution like the JVM would have saved time and effort.
I haven't used the JVM in a long time, but judging by the web framework benchmarks I've checked out this morning e.g. [0], it seems like there are many Go frameworks that beat those on the JVM.
I agree with other commenters on this thread that in general such benchmarks may not mean a lot when compute is so cheap and the autoscaling infrastructure is awesome, but I often work on embedded platforms or other resource constrained devices where adding the JVM is a nonstarter (not that Django or Rails is an option either in those cases).
Note that those benchmarks use a non-standard golang HTTP library (fasthttp I believe), which even according to it's author makes certain compromises and can be tricky to deal with, and can fail in edge cases (I'd avoid it for production). Whereas the Java versions are much more standard and safer to use.
Secondly, something seems off if a php framework is getting top place, unless it's doing some AOT compilation.
I could be wrong but I thought miners were always in sync, miners are effectively writers to the ledger and single threaded. They all mine the same transactions in the same order. The first to find the hash with correct difficulty gets the block, which triggers the other miners to stop and verify. Once verified the new block becomes the seed for the next block. So the first transaction will always be processed before the second transaction. The second transaction would be committed as long as you had enough balance remaining after the first transaction.
Not true. Each miner may choose by whatever logic which transactions to include in the block they are mining. They are however are likely to prefer those which pay higher fee.
Yeah, but now that trivial observation has a name that he coined.
And incidentally, what a terrible name. A "hash" (really hash table) is a specific implementation of a map/dictionary. You shouldn't use "hash" to refer to a map based on search trees.
It is interesting that hash is sometimes (incorrectly) used as a synonym or generic name for map/dictionaty/associative array, but Red-Black-Tree, AVL tree, etc. is not.
JVM- and Android-targeted Kotlin were built in simultaneously, whereas Android-targeted Groovy was added on last year as an afterthought, so the QA aspects of each will likely be very different. Also, the full-time developer working on Groovy's Android codebase was retrenched last year, whereas Jetbrains is still supporting Kotlin's Android codebase.
