4 ms·

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 lightwe

by corty 6y ago

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).

pjmlp 6y ago
So C has a VM apparently, https://en.cppreference.com/w/c/thread https://en.cppreference.com/w/c/thread https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html#Libgcc https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html#Libgcc https://clang.llvm.org/docs/Block-ABI-Apple.html https://clang.llvm.org/docs/Block-ABI-Apple.html
efficax 6y ago
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.
- corty 6y ago
  By that argument a x86-VM running on x86 is not a VM because there is no code translation in between.
  - lostmsu 6y ago
    Words can have different meanings in different contexts.
    - corty 6y ago
      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.
      - lostmsu 6y ago
        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.
josephcsible 6y ago
> 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.
- corty 6y ago
  Bytecode is not necessary for it to be a VM, otherwise KVM wouldn't be a VM because it just executes machine code as is mostly.
  - josephcsible 6y ago
    That's a VM in a different sense.
isp-localhost 6y ago
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.
- frou_dh 6y ago
  > 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.

by corty 6y ago

pjmlp 6y ago

So C has a VM apparently, https://en.cppreference.com/w/c/thread https://en.cppreference.com/w/c/thread https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html#Libgcc https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html#Libgcc https://clang.llvm.org/docs/Block-ABI-Apple.html https://clang.llvm.org/docs/Block-ABI-Apple.html

efficax 6y ago

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.

corty 6y ago
By that argument a x86-VM running on x86 is not a VM because there is no code translation in between.
- lostmsu 6y ago
  Words can have different meanings in different contexts.
  - corty 6y ago
    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.
    - lostmsu 6y ago
      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.

josephcsible 6y ago

> 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.

corty 6y ago
Bytecode is not necessary for it to be a VM, otherwise KVM wouldn't be a VM because it just executes machine code as is mostly.
- josephcsible 6y ago
  That's a VM in a different sense.

isp-localhost 6y ago

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.

frou_dh 6y ago
> 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.