3 ms·

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 compi

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.
- pjmlp 6y ago
  > Is the C standard library a virtual machine? 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://www.cl.cam.ac.uk/teaching/1415/CandC++/lecture10.pdf https://phoenix.labs.vu.nl/sysprog/cabs.pdf https://phoenix.labs.vu.nl/sysprog/cabs.pdf And not all C implementations AOT compile to native code.
- didibus 6y ago
  If you want to understand the differences and similarities between Go and Java in any meaningful way, you've got to discuss something more than the vague idea of a virtual machine. That's all I'm really saying. 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.

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.

pjmlp 6y ago
> Is the C standard library a virtual machine? 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://www.cl.cam.ac.uk/teaching/1415/CandC++/lecture10.pdf https://phoenix.labs.vu.nl/sysprog/cabs.pdf https://phoenix.labs.vu.nl/sysprog/cabs.pdf And not all C implementations AOT compile to native code.
didibus 6y ago
If you want to understand the differences and similarities between Go and Java in any meaningful way, you've got to discuss something more than the vague idea of a virtual machine. That's all I'm really saying. 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.