I think what I have not gotten across well enough in the article is that people think that I regard Docker as some direct substitute for JVM or CLR. Clearly it is not as it does not abstract away the CPU architecture or the OS for that matter.

But my counterpoint to that is that using something like a VM with bytecode was never the only solution to having a cross platform solution. Long before Java you had OpenStep aplications running on a diverse set of platforms, using the same technology macOS is built with today, with the bundles and/or fat binaries. We got cross compilation. We go direct distribution of binaries e.g. through the App store for your particular platform.

These kinds of alternative solution seems to work just fine. It is rare to see people who compile to native code complain about difficulty of distributing their applications. I think that is a bit of a made up problem. Docker I believe solves a more important problem which is having a standarized environment in terms of versions of libraries, filesystem layout etc.

But let me follow up on some of your points.

1) That is interesting and I honestly don't know what to make of it. To play devils advocate I would say. What makes WebAssembly any different from JVM or the CLR. What does it offer that we haven't already been given? Where is the key innovation?

2) This doesn't seem to matter much in practice though. In practice people seem to enjoy better performance with Go, Rust, Swift etc than with Java. So whatever advantage there is to JITing, it seem to be undone by the advantages of native compilation. This is of course a complex issue but I would say with native compilation it gives the developer more options of fine tuning the code by hand.

E.g. you have more control over how you layout memory so you utilize CPU cache better. I am not a Java guy but have most experience with native development so, I don't know how you would effectively reason about this in a language like Java which abstracts away a bit too much of the underlying hardware model IMHO.

This stuff obviously matters but ironically Java doesn't seem all that great at utilzing this anyway. Langauges like Julia seem far more capable. If JIT compilation is your big thing, I would rather invetigate Julia. You can even do quite a lot of static type checking with external tools. But it is optional unlike Java.

It is of course more clunky with AOT to do this, but you can imagine using a fat binary approach. Simpy compile in different code paths or different binaries.

Alternatively, you can simply build on the server. The Go toolchain e.g. is pretty simple and compile real fast. Deployment could just be a Docker cotainer with the Go toolchain that pulls the latest source code and compiles on the server.

Or I am sure people can create profiles for different servers they are deploying to and cross compiling for whatever they are deploying to. I am not sure this is really a deal breaker. I mean how often does your hardware suddenly change? I would assume a cloud deployment involves quite a lot of hardware that you have carefully selected.

But hey I am not a sever guy. I would rather call myself a tourist. I am just hiking through Java country and making some observations, that I write home about.

3) Not something I know much about. I mean I know you can record usage profiles even for native code and feed that into your build system later. So anyway I don't think this puts native compilers necessarily at a disadvantage.

4) I am not a Java guy, so it is not immediately clear to me what you are getting at.

5) I did actually mention the rest. One of my key points was that both Java and C# has a lot of sophisticated tooling which will keep them going. My point was that this is all intertia. The benefit of any language which has been around for many years and been popular. Java can coast along on this for years.

My point is that the whole underlying premise of Java, this idea that servers have a major advantage by running on a virtual machine, simply does not hold true anymore.

Few seem to really care all that much about this. You see all these new projects especially with microservices built on Go.

Ok, let me moderate this stand a bit. BEAM used by Elexir and and Erlang seems to offer some real value for developers of server side sofware with lots of concurrency that needs fault tolerance. BEAM was built for this. I cannot see the JVM really offering anything special here.

Yes you may object by dropping a long list of Java tools on me. But my question is: How much of that is down to inherent advantages of the principles Java is built upon vs simply an outcome of the popularity and age of Java?

I don't actually see the world as a universal VM thing. Maybe I need to check how I wrote that article 😁

Even since I got burned on the whole CLR idea of .NET I have rejected this utopian ideal of one VM to rule them all. I have seen repeatedly this kind of technologies come and go and it NEVER pans out.

No, I think the future will be similar to now: a variety to different VMs, JIT compilers, native compilers etc.

I am a bit old school. I think we have gone off the rails in our desire to abstract. If all we do is put layers on our existing hardware and software and then target only this universal platform, then what the hell is the point in having multiple types of hardware, software and operating systems in the first place? We could just safe ourselves a ton of problem by all running the same OS.

No, I think it is inherent in the industry that we will always want different platforms and we will often want to target specific platforms explicilty because they offer unique advantages or tradeoffs we are interested in.

I used to be a mobile developer, and I got nothing but negative experience with efforts to write programs running on all mobile platforms. Sure you can have parts that you reuse, but ultimately I think you need to tailor your solutions to the strenghts of each platform.

For me Docker and Linux is a simple realization of this. Instead of having 10 different server operating systems and then addings donts of layers on top to erase this difference, let us just make Linux the standard. That is essentially what has happened and that seems to have saved people a ton of problems.

That is why I am saying Linux is the new JVM.