5 ms·

I always liked writing VMs But we have to agree that JVM feels like steam engine running in the age of electric motors. With virtualisation available cheaply i

I always liked writing VMs 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

closeparen 6y ago
Clojure famously takes exactly the opposite tack: https://clojure.org/about/rationale#_languages_and_platforms https://clojure.org/about/rationale#_languages_and_platforms
- Scarbutt 6y ago
  That didn't aged well...
  - nlitened 6y ago
    Why? I really enjoy using Clojure, and the community is vibrant.
    - Scarbutt 6y ago
      Was referring to the "VMs are the future" part.
monadic2 6y ago
> With virtualisation available cheaply in every level (hardware, arch, OS and docker) virtualisation at runtime feels like overhead. 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?
saagarjha 6y ago
I don’t see how Go presents anything new in the portability front.
- skrebbel 6y ago
  Like Java, I can write a Go program, compile it on my computer for 3 different OSes, ship the binaries, and I can be reasonably sure that it works on other OSes. 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.
  - Alupis 6y ago
    The JVM's "write once, run everywhere" doesn't just apply to any OS that happens to have a JVM available... it means any architecture. You don't have to compile one version of your program for MIPS, ARM, x86, etc. The same bytecode will run on any JVM without being touched... something C/C++ (which were popular when Java was being created) couldn't do. > 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.
    - dirtydroog 6y ago
      This is a little bit off. The only architecture supported by Java is the JVM. It is a fictional CPU architecture with predefined characteristics, such as a memory model. The implementation of a JVM is a mapping from a real CPU to the J VM's requirements. So no, JVM doesn't mean 'any architecture', it means 'JVM'. It only applies to OSes where a JVM is available.
didibus 6y ago
There's not much difference between Go and the JVM, except one is compiled just in time and the other ahead of time. There's also been a few ahead of time compilers for Java over the years, with substrateVM being the latest one for example. From https://golang.org/doc/faq 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 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?
- shawnz 6y ago
  > Ultimately, if you abstract away the details of the running environment, to me, you've created a virtual machine. 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.
pron 6y ago
Then your feelings are wrong. No runtime environment provides anything near the JVM's combination of performance, productivity and observability. It's steam engines vs. an electric motor, alright. 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.
- entha_saava 6y ago
  I guess you work on JVM. 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?
  - pron 6y ago
    > But the opinion that Go is sluggish and opaque is purely subjective 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.
tannhaeuser 6y ago
"Steam Engine" isn't what I'd call the JVM; it's still a remarkable piece of software driving hundreds of thousands business apps with a strong focus on long-term maintenance, excellent mindshare, and really very good performance for what it does (though in somewhat of a stasis with Java9+ deprecation, and Spring-centric development). However, I get what you mean: the JVM was originally intended as a portable runtime for set-top boxes at a time when there were many ISAs (MIPS, PPC, etc.) around, and not just x86 and ARM like today. I believe Java is still a mandatory part of BlueRay disc players. It was also at one time a candidate for running in the browser (also reflected in the Java/JavaScript naming). Incidentally, Java was rejected in the browser by browser vendors, and JavaScript became "more like Java" instead, and has followed a similar path from being a browser language to being used also on the server-side (something that Netscape started already in 1996 or so). 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
- praveen9920 6y ago
  I agree all that about jvm. It had considerable impact on industry and it is nice piece of software. 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.
  - tannhaeuser 6y ago
    > But JVM has issues which recent runtimes have learnt and solved in different ways. Such as?
pjc50 6y ago
You've forgotten about different processor architectures? Even today there's Intel and ARM, but at the start there was also Sparc which Sun wanted people to use. So, just like WebAssembly, java bytecode operates as a platform-independent instruction set. (ARM provides processors with some ability to execute bytecode directly - Jazelle - but it seems to be obsolete?) 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.

closeparen 6y ago

Clojure famously takes exactly the opposite tack: https://clojure.org/about/rationale#_languages_and_platforms https://clojure.org/about/rationale#_languages_and_platforms

Scarbutt 6y ago
That didn't aged well...
- nlitened 6y ago
  Why? I really enjoy using Clojure, and the community is vibrant.
  - Scarbutt 6y ago
    Was referring to the "VMs are the future" part.

monadic2 6y ago

> With virtualisation available cheaply in every level (hardware, arch, OS and docker) virtualisation at runtime feels like overhead. 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?

saagarjha 6y ago

I don’t see how Go presents anything new in the portability front.

skrebbel 6y ago
Like Java, I can write a Go program, compile it on my computer for 3 different OSes, ship the binaries, and I can be reasonably sure that it works on other OSes. 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.
- Alupis 6y ago
  The JVM's "write once, run everywhere" doesn't just apply to any OS that happens to have a JVM available... it means any architecture. You don't have to compile one version of your program for MIPS, ARM, x86, etc. The same bytecode will run on any JVM without being touched... something C/C++ (which were popular when Java was being created) couldn't do. > 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.
  - dirtydroog 6y ago
    This is a little bit off. The only architecture supported by Java is the JVM. It is a fictional CPU architecture with predefined characteristics, such as a memory model. The implementation of a JVM is a mapping from a real CPU to the J VM's requirements. So no, JVM doesn't mean 'any architecture', it means 'JVM'. It only applies to OSes where a JVM is available.

didibus 6y ago

There's not much difference between Go and the JVM, except one is compiled just in time and the other ahead of time. There's also been a few ahead of time compilers for Java over the years, with substrateVM being the latest one for example. From https://golang.org/doc/faq 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 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?

shawnz 6y ago
> Ultimately, if you abstract away the details of the running environment, to me, you've created a virtual machine. 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.

pron 6y ago

Then your feelings are wrong. No runtime environment provides anything near the JVM's combination of performance, productivity and observability. It's steam engines vs. an electric motor, alright. 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.

entha_saava 6y ago
I guess you work on JVM. 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?
- pron 6y ago
  > But the opinion that Go is sluggish and opaque is purely subjective 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.

tannhaeuser 6y ago

"Steam Engine" isn't what I'd call the JVM; it's still a remarkable piece of software driving hundreds of thousands business apps with a strong focus on long-term maintenance, excellent mindshare, and really very good performance for what it does (though in somewhat of a stasis with Java9+ deprecation, and Spring-centric development). However, I get what you mean: the JVM was originally intended as a portable runtime for set-top boxes at a time when there were many ISAs (MIPS, PPC, etc.) around, and not just x86 and ARM like today. I believe Java is still a mandatory part of BlueRay disc players. It was also at one time a candidate for running in the browser (also reflected in the Java/JavaScript naming). Incidentally, Java was rejected in the browser by browser vendors, and JavaScript became "more like Java" instead, and has followed a similar path from being a browser language to being used also on the server-side (something that Netscape started already in 1996 or so). 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

praveen9920 6y ago
I agree all that about jvm. It had considerable impact on industry and it is nice piece of software. 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.
- tannhaeuser 6y ago
  > But JVM has issues which recent runtimes have learnt and solved in different ways. Such as?

pjc50 6y ago

You've forgotten about different processor architectures? Even today there's Intel and ARM, but at the start there was also Sparc which Sun wanted people to use. So, just like WebAssembly, java bytecode operates as a platform-independent instruction set. (ARM provides processors with some ability to execute bytecode directly - Jazelle - but it seems to be obsolete?) 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.