While the article overall might not be totally wrong, at least two details are dead wrong.
Go DOES have a virtual machine, thats what gives you all the lightweight threads and garbage collection. You may call it "runtime", but there is no difference between a heavyweight runtime or a lightweight VM.
And go DOES have exceptions, thats what panic does. The are just used less frequently than in other languages (e.g. Java, where even the happy path may contain exceptions, e.g. in Swing).
A "runtime" is not a virtual machine anymore than the standard c library is a virtual machine... it's clear what virtual machine means in this context: an abstraction layer between machine code and program code that translates one to the other at runtime.
Yes, but here they don't. A VM is a non-physical machine that executes instructions. Nothing more, nothing less. And yes, this means that even a library might be considered a VM. I don't see why people get so wound up about that.
Because half of your point is nonsensical without that stretch of the meaning in regards to VMs.
Go programs do not run on a VM. They run on a specific CPU architecture, and specific OS. You would need an actual VM to run the same program on something different. That is unlike Java which on its own is a VM to run programs on.
I would argue the other half of your point is nonsensical in the same matter. You just conflated two different definitions of exceptions, which are similar, and have intersections, but not identical.
> there is no difference between a heavyweight runtime or a lightweight VM.
There's a big difference. A runtime is just functions that get called, but a VM means that you have bytecode that it's interpreting instead of native code.
Go's error type is something declared as being returned from a function, there's no try-catch with an exception being handed up a call stack. That's like saying ASM has exceptions because you can leave an error code in one of the registers.
The VM bit doesn't make sense to me at all. By that logic any language which implements a GC or has a native support for threads constitutes a VM?
There's no difference between a runtime and a VM? As an embedded developer I would argue that there's quite a difference between the two.
edit: Clarification on error type being "always" returned from a function.
> Go's error type is something declared as being returned from a function, there's no try-catch with an exception being handed up a call stack. That's like saying ASM has exceptions because you can leave an error code in one of the registers.
But Go's functions "recover()" and "panic(...)" are very much like "catch" and "throw" and are all about the callstack. There's just no "try", because this special snowflake implementation of exceptions works with slightly coarser granularity than is typical (function granularity instead of block granularity), since it's living under the same roof as the error type.
Go DOES have a virtual machine, thats what gives you all the lightweight threads and garbage collection. You may call it "runtime", but there is no difference between a heavyweight runtime or a lightweight VM.
And go DOES have exceptions, thats what panic does. The are just used less frequently than in other languages (e.g. Java, where even the happy path may contain exceptions, e.g. in Swing).