But we have to agree that JVM feels like steam engine running in the age of electric motors. With virtualisation available cheaply in every level (hardware, arch, OS and docker) virtualisation at runtime feels like overhead.
JVM was originally created for purpose of 'write once, run anywhere', which I think can be addressed in alternative ways, look at golang
Edit: also I want to mention that Java was IMO the single one tech that saved the scene from being an Microsoft-only world, and also significantly paved the way for today's Linux dominance on the server-side; Java was picked by many devs because it helped to keep open the door for migrating to Solaris or Linux in an increasingly MS-dominated landscape in mid 90's
But you missed my point entirely. I did not call JVM a steam engine in derogatory way. On the contrary, steam engine is awesome piece of technology which had tremendous impact on industry.
But JVM has issues which recent runtimes have learnt and solved in different ways.
Such as?
From https://golang.org/doc/faq they say:
> Go does have an extensive library, called the runtime, that is part of every Go program. The runtime library implements garbage collection, concurrency, stack management, and other critical features of the Go language
I think people can argue all they want about semantics, what is a virtual machine? There are not "proper definition" for this. Ultimately, if you abstract away the details of the running environment, to me, you've created a virtual machine.
The Go FAQ continues by insinuating it isn't a virtual machine because it doesn't do just in time compilation and only ahead of time. I think that's just word play.
From https://en.m.wikipedia.org/wiki/Virtual_machine says:
> A process VM, sometimes called an application virtual machine, or Managed Runtime Environment (MRE), runs as a normal application inside a host OS and supports a single process. It is created when that process is started and destroyed when it exits. Its purpose is to provide a platform-independent programming environment that abstracts away details of the underlying hardware or operating system and allows a program to execute in the same way on any platform.
Personally, I think "Managed Runtime Environment" is a better term, and Go would definitely fall into that term.
So I recognize the difference are real. Just in time Vs ahead of time. But it isn't docker, or any other layer of virtualization which magically allow Go to run over many machines. Its because it has an extensive runtime that abstracts away their details. And this runtime has to be bundled in every compiled application. Maybe we should start talking about virtual runtimes?
So then are operating systems also virtual machines? Is the C standard library a virtual machine? This seems like a pointless definition to me.
> Maybe we should start talking about virtual runtimes?
Isn't that just called a runtime? Java is "virtual" because the instructions in the Java class files don't run directly on the CPU, unlike Go where the instructions in the binary do run directly on the CPU.
Here it seems specifically like OP wanted to say that they find ahead of time statically linked with cross compilation to be a more convenient model of code compilation and distribution.
With that in mind, we're now better equipped to compare and contrast, and discus the pros/cons.
When we restricted ourselves to VM vs non-VM, I didn't feel like we were in this meaningful zone.
And from that angle for example, we can see that Java offers ahead of time compilation, which can be statically linked as well if one wants too. One example is GraalVM native image. There were also some options before GraalVM that I think were all commercial. That said, I've yet to see a cross-compilation offering.
The JIT approach has benefits as well, the user doesn't need to select the appropriate package for their OS. The runtime distribution is shared between all apps that uses it. It's easier to offer debugging/profiling/measuring capabilities of the running application. The user can tweak certain parameters of the runtime or even choose an alternative runtime implementation. If runtime has any known security vulnerability, the user can upgrade it to a new secure version, without waiting for a new update of the app. Better peek performance of hot code paths can in theory be achieved. Just to name a few.
Another difference is Go has no intermediate representation. While Rust, C# and Java for example do. This intermediate representation is quite useful in allowing multiple languages to reuse the Java bytecode runtime. That's not as simple in Go, since Go is a harder target for compilation.
Etc.
Kind of, the ISO C is defined in terms of the C abstract machine.
> The semantic descriptions in this International Standard define a parameterized nondeterministic abstract machine. This International Standard places no requirement on the structure of conforming implementations. In particular, they need not copy or emulate the structure of the abstract machine. Rather, conforming implementations are required to emulate (only) the observable behavior of the abstract machine as explained below.
https://www.cl.cam.ac.uk/teaching/1415/CandC++/lecture10.pdf
https://phoenix.labs.vu.nl/sysprog/cabs.pdf
And not all C implementations AOT compile to native code.
Virtualisation is also not readily available from within userland. We're not at "each process runs in its own VM" yet. Perhaps we'd want "each browser tab runs in its own VM", which is kind of what Javascript aims to achieve.
Microsoft have also gone in this direction; they don't call the CLR a "VM" but it performs many of the same functions in order to run CIL/MSIL bytecode.
Yes, there is a cost in footprint and warmup, but footprint is very often (though not always) the right cost. Of all software resources -- development, maintenance, memory, processing and bandwidth -- it's the cheapest (well, second to storage). By comparison Go is less RAM hungry but it's sluggish and opaque.
But the opinion that Go is sluggish and opaque is purely subjective. For anything but long running server apps, Java's memory consumption makes it feel sluggish, especially on desktop.
Also, when are the value types coming?
It is not. It's significantly slower than Java and has maybe 5% of its observability tools. Go is technologically more than a decade behind Java in compilation, GC, and observability. I'm not saying it's not good enough for certain things -- sometimes primitive and simple gets the job done, and you might not need a Ferrari to go to the grocery store -- but let's not turn an acceptable compromise into a win.
> Java's memory consumption makes it feel sluggish
Why? If you don't mind it performing as poorly as Go, you can reduce the heap size and pick a low-latency collector like ZGC, but really Java says, give me the cheapest resource, RAM, and in return you'll get something much better.
> especially on desktop
Java desktop applications consume less RAM than Electron ones, and IntelliJ is more snappy than Atom (and recently, unfortunately, vscode, too), although there are perfectly valid reasons to prefer Electron.
> Also, when are the value types coming?
I don't know. Not my area.
All of this has been possible for decades (eg cross compile C++), but Go is the first mainstream compiled-to-native language that I know that makes it easy. Thanks to this, I can run many utilities written in Go on my Windows box, written mostly by people who likely never even tested in on Windows. That's pretty amazing to me.
People just drop a Windows binary on GitHub and think "I'll get the PR if stuff doesn't work". They'd never do that if it cost them effort to cross build a Windows binary. People didn't do that before Go, and many modern OSS command line utilities / server apps only worked on unixes.
> and many modern OSS command line utilities / server apps only worked on unixes
This, I think, likely has more to do with being POSIX compatible and/or oriented for headless server usage where a shell is "home" for many 'nix admins.
The developer no longer cares what architecture the program will run on, it just works.
You compile to bytecode, and stop caring. The JVM becomes your only target architecture, regardless of what actual architecture the system has.
That's unlike C or pretty much any (all?) other compiled languages around in the early 90's when Java was still Oak and Gosling was just getting started.
With Java, you compile one “binary” and it works not just on three OSes, but all of them that have a JVM available. The beauty of it is that it’s as portable as an interpreted language, no cross-compilation needed at all.
But there's plenty use cases for which the go standard library offers a sufficiently good abstraction that cross compiling just works. The same holds for JVM apps for ages (and for nodejs etc etc) but not eg for C(++).
As a windows dev I very much noticed an increase in good CLI tools that just work on my box since Go got to the scene. I think that's cool.
These seem to be solving fundamentally different problems. Where do you see the overlap that might be able to be moved out of the jvm?