> So, JVMs and languages that abstract the underlying machine are always going to have overhead.
Well, so JavaScript and WebAssebly isn't that great either in the end?
> The original interpreted stack-based JVM model is really bad for performance because you can't do great optimizations on the code because you can't have a great view of the operands that are being defined and then subsequently used, on top of that you have to either JIT or interpret code which also has overhead.
What a paragraph. But it's kinda false.
WebAssembly, you know, is also a stack-based virtual machine.
Javascript might not be a stack-based virtual machine, but you're interpreting it every time you run it for the first time. How is that faster that bytecode? It isn't.
In fact, modern Javascript is fast specifically because it copies the same workflow of the Java HotSpot JIT optimizer - detect and compile code hot spots in native code, run that instead of VM code.
> This is why Android's original Dalvik VM originally started by converting the Sun byte code format to a register based format. So, now you have a format you can do some optimizations on: great. But you still depend on a VM to generate and optimize for native code: that means code-caches and that means using excess memory to store the fast optimized code you want to run (which could have been evicted, so more overhead when you have to regenerate).
Nope, that is totally not the reason. Dalvik was done because it was believed that you needed something that starts faster, not something that runs faster.
Those are 2 different optimization targets.
It was pretty known since the start of Dalvik that Dalvik had very poor throughput performance, from 10x to 2x worse that HotSpot.
The reason why we don't have Dalvik anymore on Android is that it also didn't start that much faster either.
That of course is not because register machines are worse either, but because nowhere near enough optimization work was done for register type VMs compared to stack type VMs in general.
> Next you have frameworks like the classic Swing in Java that were frankly implemented with priorities that did not include having a really great and responsive experience even though its platform agnostic as far as the way it draws widgets. These days we can take GPUs for granted to make this approach work, but a lot of the Java UI stuff came from another era.
Ok, but does your favorite, non-web GUI framework use the GPU, and use the GPU correctly at all?
Even on the web it's easy to "accidentally" put some extremely expensive CSS transformations and animations and waste a whole bunch of GPU power on little things.
> I am not really sure if I am right here, but to me all this means that to have made the Java system work well for modern PCs and mobile it would have required a ton of investment. As it turns out, a lot of that investment went into the web and android instead of polishing Sun and Oracle's uh... product.
You're mixing things here. "Sun products" were very expensive UNIX workstations and servers. Not things for your average Joe. Those very expensive Sun workstations and servers ran Java fine.
Java itself is a is very weird "Commoditize Your Complement" ( https://gwern.net/complement ) attempt to commoditize this exact very expensive hardware that Sun was selling.
From Sun. Marketed at very high expense by Sun. A self-inflicted self-own. No wonder Sun no longer exists.
> Java's also kinda been sidelined because for years Oracle threatened to sue anyone that dared fork it as Google had, and Microsoft kinda spent a decade making C# and .NET more confusing than it already was so theres that too.
C# not having nice GUI is another story, that of Windows-land never having anything above pure Graphics Device Interface being stable since forever.