Modern CPU+OS is a good-enough hardware VM and a target platform. Process isolation under an OS is a right level of abstraction.
A VM as user-level OS process which tries to do an OS job and reimplement everything inside a VM is simply ridiculous. Javascript follows the same madeness.
Multi-threading for imperative code is a big mistake, which breaks isolation and results in lock-hell, context-switching nightmare and layers of unnecessary complexity which is impossible to reason about.
At cost of wasting of almost as much resources that it serves.
Top is about popularity, not quality. Junk-food is also popular.
My analysis was about the first principles, not abstract ones, but grounded in reality. Those who got the principles right wins in the long run.
Erlang (where VM is not a byte-code interpreter), Golang, Haskell (except when monads are abused by idiots), etc are designs based on the right principles. Java was a primitive religion based on superstitions (the fear of pointers) from the start.
Performance on a simplified task is the least important metric.
BTW, it will be wonderful to see next to these charts "memory used" and "lines of code used, including all dependencies" columns. And "length of stack trace in kilobytes" of course.
Sorry, I didn't read this particular link. I have seen too many of them before. Principles are above particularities.)
Edit: an illustration - closer to real world example chart from the same site:
Let me illustrate the thesis about necessity of proper abstractions and principles grounded in reality in another way.
There are way too many cases of a meaningless bloatware in human history, including writings produced by Hegel, Marx and Engels. There are millions of people suffered because these graphomans have produced 4000+ pages of so-called [political] philosophy, full of pure abstractions, abstract concepts and meta-phisical design patterns. The shit doesn't fly, except for confusing minds of bunch of lesser idiots, which ruined whole nations afterwards.
On the other hands, there are writings after "down to earth" guys, such as Buddha or Christ, or to lesser extent, the guys who wrote Upanishads (which uses rather poetical language) which literally saved, or at least improved, billions of lives. In the realm of philosophy, guys like Tomas Hobbes and Adam Smith wrote much less pages and described some aspects of reality way better.
Piling up layers upon layers of disconnected from reality crap of wrong abstractions and dubious abstract principles, praised by brainwashed followers, especially because they are too bogus and too abstract, is a way to ruin.
I think it is not too hard to notice rather striking similarities.)
No. Not acceptable. You seem to have forgotten what a VM IS. It stands for VIRTUAL MACHINE. The idea is that you can run the VIRTUAL MACHINE on top of ANY PHYSICAL ARCHITECTURE, and have the applications work, so long as the machine's basic assumptions are followed (i.e. there's some kind of I/O, and a screen capable of displaying graphics, for most of them). A well designed VM can be re-implemented anywhere, and have the software run on it just work. Just look at the Z-machine, or the squeak VM.
The problem with a modern CPU+OS as a VM is that it cannot be re-implemented on other hardware effectively. you can't pull a piece of software designed to run on the x86+unix "VM" and write a VM to make it run on ARM+Windows. Not fast, not in a way that you'd want to use. Try writing native code translation fast enough that you can run Quake3 without even noticing the difference. That's why VMs exist.
The original rationale for the JVM -- "write once, run anywhere" -- no longer exists since nobody downloads applets anymore.
The more sensible technology for making code run on multiple platforms still works quite well. It's called a compiler.
Not if you make OS specific syscalls. Your system has to account for the fact that not everybody runs on the same system. VMs do that, and do it far better than most compilers, when it comes to reliable cross-platform without doing a ton of re-writing.
> Multi-threading for imperative code is a big mistake, which breaks isolation and results in lock-hell, context-switching nightmare and layers of unnecessary complexity which is impossible to reason about.
Go is multithreaded and imperative. Sure, it has some nice concurrency features to help you untangle it, but all of the dangers of shared memory multithreading is right there.
…as is Swift with NSOperation/GCD. Apple's process isolation tech (XPC) is built upon their multithreading tech (GCD). The two are complementary, not antagonistic.
Doing multithreading on a runtime with automatic reference counting gc and expecting performance is nuts. Every reference assignment is a potential write contention.
It is possible to do it, even sensible when you need it for GUIs for example. Just don't expect it to use the hardware in a sensible manner.
A VM as user-level OS process which tries to do an OS job and reimplement everything inside a VM is simply ridiculous. Javascript follows the same madeness.
Multi-threading for imperative code is a big mistake, which breaks isolation and results in lock-hell, context-switching nightmare and layers of unnecessary complexity which is impossible to reason about.
Golang and Swift guys got it.