Haven't we learned that VMs aren't worth it? The amount of engineering resources it takes to design a half-way decent one is just absolutely staggering. We all know that theoretically they can be faster than native code, but how many people have actually experienced that? The costs are too high: the warm-up costs, the engineering costs, the complexity costs. If every single language just generated LLVM IR and compiled it, we'd be in a lot better place and we'd probably have better, or at least more predictable, performance.
Like more resources have probably been put into the JVM than any other VM or compiler on earth and what has it given us, exactly? Performance is still worse than C and with homogenized operating systems, as well as the move towards the web, the portability guarantees don't feel very important. If I'm missing something, please tell me!
The same can also be said about GC. Every year somebody is promoting a new Incremental Realtime Generational garbage collector that is almost acceptable for serious work, if you ignore enough real-world overheads. People writing code that has to manage resources besides memory have found that, given the right core language facilities, managing memory too is no bother, but managing other resources while fighting GC is intolerable. Of vourse you need destructors.
Meanwhile, C performance has not been a worthy goal in decades. Getting "as fast as C", if you could get there, would still leave you firmly in second or third place. Thr computers are not getting much faster anymore, but the problems are getting much bigger and the networks much faster, so performance matters more each year than the last.
> The computers are not getting much faster anymore
True for each core on a CPU (broadly) but not true for the computer as a whole unit, we've seen an explosion of core counts on x86 desktops/laptops over the last 5 years (helped by the resurgent AMD forcing Intel to stop putting out incremental upgrades to 2C/4T on laptop and 4C/8T on desktop every year).
> People writing code that has to manage resources besides memory have found that, given the right core language facilities, managing memory too is no bother,
If we assume that it is 'no bother' as stated that doesn't address the 8C/16T elephant in the room in that for maximum throughput on a modern machine we need to orchestrate running across multiple cores properly and that's a tougher problem to crack in a general purpose popular language without an explosion in complexity to the programmer.
That's a True Scotsman fallacy. I guess all those millions upon uncountable millions of lines of Java, Erlang, C#, etc code in production is not serious? Because it's running in a VM?
I believe that's why the poster referenced the "No True Scotsman" fallacy. It entirely depends on your definitions and you can keep endlessly narrowing your definitions. All of them GC, right? All of them are doing some form or another of incremental, right? (Some in all generations, others only in some generations, based on balancing and tuning needs.) Do all of them have realtime characteristics? Yes and no. None of them are allowed to stop the world, certainly, but does that mean that all of them or any of them can be called "realtime"? It's a semantic hedge forest.
The difference is that GC provides so much more value than a VM. For example, without GC, functional programming is practically impossible, unless you consider linear types the solution (I'm not aware of a FP language that uses them instead of GC, so I can't really comment on their viability).
Performance is I think for most people a matter of good-enough performance, most of the time, with good-enough and most varying wildly depending on context.
Regarding the move towards the web, I think portability still matters, because a lot of web developers write code and potentially test code on Windows and but deploy on Linux for production.
Except it's not good enough. Every JVM project I've worked on had to work around the unpredictability of the VM: doing things like on a new deploy hitting all your endpoints a 100 times in order to warm things up. Or the curious cases when a trivial change in one part of your program somehow affects the performance characteristics of another. VMs don't provide enough benefits to justify the large burden of actually using them effectively.
Like more resources have probably been put into the JVM than any other VM or compiler on earth and what has it given us, exactly? Performance is still worse than C and with homogenized operating systems, as well as the move towards the web, the portability guarantees don't feel very important. If I'm missing something, please tell me!