[wejick]

go runtime is not VM like JVM [0]. Go doesn't run on top of runtime, more like run along side it. That's why there's go for embedded where it has no runtime. So it's very less likely other language reuse go runtime.

[0] https://go.dev/doc/faq#runtime

[pjmlp]

There are also bare metal JVMs for embedded development, here are the two best ones.

https://www.ptc.com/en/products/developer-tools/perc

https://www.aicas.com/wp/products-services/jamaicavm/

And while we are at it, for .NET as well,

https://www.wildernesslabs.co/

[kaba0]

There is absolutely no real difference between the two. One just bundles the code with the runtime while the other doesn’t and uses an intermediary format.

[simiones]

I would wager there are far more embedded devices running Java than Go. Though, to be fair, it's usually a stripped-down version of Java.

[int_19h]

Go doesn't have bytecode interpreter or JIT, but it still needs a VM, if only for green threads.

[cygx]

Not every runtime environment is a virtual machine...

[int_19h]

That's true, but I would argue that any runtime with custom green threads is.

[cygx]

Would you consider the C runtime a virtual machine once you link against libdill or use OpenMP? If not, why not? If so, well, then we just disagree on the term 'virtual machine'. My litmus test would be the presence of some sort of well-defined instruction set.

[int_19h]

A quick look at libdill indicates that concurrency there is cooperative, so it's not green threads, either. So, that's just a library.

OpenMP uses OS threads, doesn't it?

When you have coroutines that can be preempted, without explicit yielding in the source code, that's the line at which I would consider it a VM. Basically, it's a VM if some userspace code (JIT, GC, scheduler etc) runs in the background and does things to your code.

I don't think there's a definitive interpretation of VM, so this is all arguable. But e.g. Java and C# are generally considered VM languages even if AOT-compiled, despite the fact that there's no bytecode involved past that point.

[cygx]

Historically, goroutines worked like in libdill, only passing control to the scheduler on certain calls. So did the Go runtime suddenly become a VM at version 1.14, when preemption was added?

And why the distinction between OS threads and green threads? Sure, in case of OS threads, it's not the language runtime that does the scheduling, but that just means that the operating system is now our virtual machine.

I would argue that what makes a language runtime a virtual machine is not the presence of a garbage collector, a jit compiler, or a scheduler (with or without preemption), but that it has well-defined semantics in terms of something that looks a bit like a real machine - hence the name! In particular, there's a set of instructions it understands. In case of the JVM, the instruction set is defined in the Java Virtual Machine Specification (with Java bytecode its representation), in case of the CLR, it's defined in the Common Language Infrastructure specification (with CIL bytecode its representation), in case of Smalltalk, it's defined in the Blue Book, in case of WASM, in the WebAssembly core specification.

[kaba0]

Then you can sure list some differences between go's and JVM's runtime.

[cygx]

Most relevant in context of our discussion: The JVM is a (virtual) stack machine with its own instruction set and semantics specified in the Java Virtual Machine Specification. As far as I'm aware, something equivalent does not exist for Go, or as an internal implementation detail at best (some intermediate representation might potentially qualify if you squint at it the right way).

[kaba0]

That's also an implementation detail, because the majority of execution time happens in native code with a native GC "managing it" the exact same way, not by interpreting abstract virtual machine instructions.

[cygx]

It's not an implementation detail, the interface is mandatory and public (Java bytecode).