7 ms·

That's about right in aggregate, though some of the specifics go either way. I have two theories why so many people are convinced that Go is much lower level th

That's about right in aggregate, though some of the specifics go either way. I have two theories why so many people are convinced that Go is much lower level than it actually is, and I'm not sure which one is true: a) Go was really sold as a "systems programming language" early on. Maybe some adopters never really questioned what that means or if that's true? b) Go produces actual executables, with what in Java would be the JIT executed ahead of time and any runtime bits statically linked in. That is completely orthogonal to abstraction level, of course. But maybe the fact the there's no externally visible runtime makes people group the language into a bucket with C?

gameswithgo 5y ago
I agree completely with your reasons. Generally, people just have no idea what is going on.
dwohnitmok 5y ago
There's a couple of things that make Go feel lower level than Java. The first is having access to pointers and the manipulation that brings. Even though there isn't pointer arithmetic, needing to think about referencing and dereferencing structs is lower level than Java, which doesn't provide this in the language at all and forces all objects to be pointer-heavy references of references (apart from primitives). The other thing is that by not having a VM, a lot of usual Go performance optimizations end up being "closer to the metal." E.g. optimizing struct alignment is a fairly pedestrian Go performance optimization. On the other hand, if you rely on guarantees of how the Hotspot JVM (as opposed to other JVMs) lays things out in memory, that's considered pretty deep hacking in Java.
- feffe 5y ago
  You do have more precise control over the memory layout of your data in Go. Because of the value types and support for using interior pointers to arrays. In that respect it's like C which is lowish level.
- azth 5y ago
  You can know your class alignments in Java using tools like http://openjdk.java.net/projects/code-tools/jol/ http://openjdk.java.net/projects/code-tools/jol/ Having access to pointers is a superficiality. Java is getting value types, and C# already has them.
  - dwohnitmok 5y ago
    Right but those tools are VM-specific (e.g. the one you've posted is Hotspot-specific) and VM-specific optimizations are usually considered advanced optimizations in Java. Valhalla's value types aren't the same thing as pointer access (or lack thererof). The first thing is that this is baked into the definition site rather than being something that can be decided at a call site. The second thing is that value types entail way more than just pointer access (as befits a higher-level approach). In particular it gets rid of the built-in ability of Java objects to act as locks, gets rid of mutation, etc. It's a much larger change than just referencing and dereferencing. More to the point, the notion of pointers referencing and dereferencing is a lower level concept than reference vs value types. The former is usually used to implement the latter.
    - azth 5y ago
      > More to the point, the notion of pointers referencing and dereferencing is a lower level concept than reference vs value types. The former is usually used to implement the latter. If the end result is the same, then the claim is really meaningless. I'm just pointing out the parroting that goes on in the golang community.
      - dwohnitmok 5y ago
        > If the end result is the same, then the claim is really meaningless. One being used to implement the other doesn't mean the end result is the same (you cannot use value types and reference types to implement pointers because of the call-site vs definition-site distinction). As I mentioned, value types are far more than pointer dereferencing.
- int_19h 5y ago
  If these are really the two sticking points, then Go should be on roughly the same abstraction level as C#/.NET (which also has pointers - with arithmetic, even! - and user-defined value types with explicit layout control and unions). However, given that Go also brings its green threading into the picture, I'd argue that it's actually higher level than either Java or .NET in that one respect.
  - dwohnitmok 5y ago
    C# is an interesting case. You can only use pointers in unsafe C# code, so you could argue that unsafe C# code is as low-level as Go or even lower (which I actually think you'll find many supporters for), but unsafe C# is different from normal C# and is outside the purview of everyday C# code (whereas again pointers in Go are absolutely pedestrian). RE threading, green threads though are coming (back!) to Java as well with Loom, but I consider that more of a library/runtime thing than a language thing (as is the case with Loom). A hypothetical Go library could expose system threads and have an API for manipulating them, it just wouldn't be first-class in the same way goroutines are. But this is similar to how having async-await in C# doesn't negate the fact that you can use direct system threads from the standard library.
    - int_19h 5y ago
      With C# and .NET, you also need to consider the different kinds of pointers involved. The thing that's closest to Go's pointers would be managed references (which don't have pointer arithmetic but are GC-aware). In C#, this corresponds to in/ref/out parameters, locals, and return types. Now, the difference is that those can point directly to the stack, and thus cannot escape the function in which they were created for memory safety reasons. But conversely, they are allowed in safe code. And then there's stuff like Span, which these days lets you do something similar to Go slices: Span<byte> p = stackalloc byte[n]; (note that this is also safe code!) As for green threads, I think in case of Go they can't really be considered a library thing due to language integration of goroutines and channels. It's also not quite the same as C# async/await, because the latter isn't really a threading system so much so as syntactic sugar for CPS; it's entirely possible to have a single thread running the event loop.
marcosdumay 5y ago
Go has a C style error handling that by virtue of being very bad, composes a large share of the code one writes. That pushes people impression of it near the one of C, even though it has some very high-level features.

gameswithgo 5y ago

I agree completely with your reasons. Generally, people just have no idea what is going on.

dwohnitmok 5y ago

There's a couple of things that make Go feel lower level than Java. The first is having access to pointers and the manipulation that brings. Even though there isn't pointer arithmetic, needing to think about referencing and dereferencing structs is lower level than Java, which doesn't provide this in the language at all and forces all objects to be pointer-heavy references of references (apart from primitives). The other thing is that by not having a VM, a lot of usual Go performance optimizations end up being "closer to the metal." E.g. optimizing struct alignment is a fairly pedestrian Go performance optimization. On the other hand, if you rely on guarantees of how the Hotspot JVM (as opposed to other JVMs) lays things out in memory, that's considered pretty deep hacking in Java.

feffe 5y ago
You do have more precise control over the memory layout of your data in Go. Because of the value types and support for using interior pointers to arrays. In that respect it's like C which is lowish level.
azth 5y ago
You can know your class alignments in Java using tools like http://openjdk.java.net/projects/code-tools/jol/ http://openjdk.java.net/projects/code-tools/jol/ Having access to pointers is a superficiality. Java is getting value types, and C# already has them.
- dwohnitmok 5y ago
  Right but those tools are VM-specific (e.g. the one you've posted is Hotspot-specific) and VM-specific optimizations are usually considered advanced optimizations in Java. Valhalla's value types aren't the same thing as pointer access (or lack thererof). The first thing is that this is baked into the definition site rather than being something that can be decided at a call site. The second thing is that value types entail way more than just pointer access (as befits a higher-level approach). In particular it gets rid of the built-in ability of Java objects to act as locks, gets rid of mutation, etc. It's a much larger change than just referencing and dereferencing. More to the point, the notion of pointers referencing and dereferencing is a lower level concept than reference vs value types. The former is usually used to implement the latter.
  - azth 5y ago
    > More to the point, the notion of pointers referencing and dereferencing is a lower level concept than reference vs value types. The former is usually used to implement the latter. If the end result is the same, then the claim is really meaningless. I'm just pointing out the parroting that goes on in the golang community.
    - dwohnitmok 5y ago
      > If the end result is the same, then the claim is really meaningless. One being used to implement the other doesn't mean the end result is the same (you cannot use value types and reference types to implement pointers because of the call-site vs definition-site distinction). As I mentioned, value types are far more than pointer dereferencing.
int_19h 5y ago
If these are really the two sticking points, then Go should be on roughly the same abstraction level as C#/.NET (which also has pointers - with arithmetic, even! - and user-defined value types with explicit layout control and unions). However, given that Go also brings its green threading into the picture, I'd argue that it's actually higher level than either Java or .NET in that one respect.
- dwohnitmok 5y ago
  C# is an interesting case. You can only use pointers in unsafe C# code, so you could argue that unsafe C# code is as low-level as Go or even lower (which I actually think you'll find many supporters for), but unsafe C# is different from normal C# and is outside the purview of everyday C# code (whereas again pointers in Go are absolutely pedestrian). RE threading, green threads though are coming (back!) to Java as well with Loom, but I consider that more of a library/runtime thing than a language thing (as is the case with Loom). A hypothetical Go library could expose system threads and have an API for manipulating them, it just wouldn't be first-class in the same way goroutines are. But this is similar to how having async-await in C# doesn't negate the fact that you can use direct system threads from the standard library.
  - int_19h 5y ago
    With C# and .NET, you also need to consider the different kinds of pointers involved. The thing that's closest to Go's pointers would be managed references (which don't have pointer arithmetic but are GC-aware). In C#, this corresponds to in/ref/out parameters, locals, and return types. Now, the difference is that those can point directly to the stack, and thus cannot escape the function in which they were created for memory safety reasons. But conversely, they are allowed in safe code. And then there's stuff like Span, which these days lets you do something similar to Go slices: Span<byte> p = stackalloc byte[n]; (note that this is also safe code!) As for green threads, I think in case of Go they can't really be considered a library thing due to language integration of goroutines and channels. It's also not quite the same as C# async/await, because the latter isn't really a threading system so much so as syntactic sugar for CPS; it's entirely possible to have a single thread running the event loop.

marcosdumay 5y ago

Go has a C style error handling that by virtue of being very bad, composes a large share of the code one writes. That pushes people impression of it near the one of C, even though it has some very high-level features.