6 ms·

Go is at about the same abstraction level as Java, maybe a fraction slower due to lack of runtime VM optimisations.

by melony 5y ago

codeflo 5y ago
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.
- 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.
Thaxll 5y ago
It's slower or faster but certainly not overall slower. By default Go will be faster because of the difference of value types between the two languages, Go is also easier to optimize since the language is simpler and has less abstraction.
- melony 5y ago
  Go can be much, much faster if fast compile times is not focus. A good compiler can probably do some compile-time RAII inlining like C++ and Rust and reduce GC usage without needing any major changes to the core Go language. A lot of the more advanced optimizations done by LLVM are not implemented in Go because they slow down compilation. Go compiles insanely quick (like classic Pascal/VB), it feels more like a JITed language than compiled.
  - kaba0 5y ago
    > Go compiles insanely quick Compared to Java?
    - throwaway894345 5y ago
      He's implying that it's comparable to Java in that it compiles fast: > it feels more like a JITed language than compiled
    - geodel 5y ago
      Yeah, and one need to compare `go build` with `mvn clean compile/package` not javac. Because Java does not come with inbuilt tools to compile whole projects.
  - throwaway894345 5y ago
    Does RAII make code faster? I thought RAII just meant things were freed as soon as they went out of scope rather than waiting for the next GC sweep? Seems like this would make code slower (instead of one free() for all garbage, you have to do a free() for each allocation). Granted, the tracing burden is lower, but I'm of the impression that tracing is cheap?
tomohawk 5y ago
This is not our experience at all. Our experience is that typical Java programs will consume a lot more memory, and spend a lot more time doing GC and other unproductive work than typical Go programs. Go provides a lot more tools that give more bang for the buck when optimizing. For example, everything in Java is a reference to some other distant blob of memory. This does not work well on todays cpus compared to being able to colocate things. We run more stuff on the same machines than we could with Java. Team wise, Go is easier to learn, and scales better with teams. We don't have trouble with team members struggling with certain team member's code / abstractions like we did with Java or C++. Switching between the two, there is a lot more cognitive overhead in Java land. It's understandable that this may be boring to some, but it is a great feature of the language.
- kaba0 5y ago
  > and spend a lot more time doing GC and other unproductive work than typical Go programs That’s definitely way in the other direction - Java’s GCs run circles around Go’s. (Part of) the reason for Java’s bigger memory consumption is that it is very lazy when it comes to GC. Go runs it all the time for lower latency (at the price of much lower throughput) while Java allows for control it.
  - geodel 5y ago
    Java GC has to be very good considering Java could take 10 times more memory for typical data structures compared to memory efficient layouts.
    - kaba0 5y ago
      Not sure if sarcastic, but that has nothing to do with the quality of a GC algorithm. Sure, Java does not (yet) have value types so data structures with non-primitive elements will not have the most optimal layout, but java does objectively have the state of the art GC implementations that work under so high allocation rates that other GCs simply break down. Eg. Go notably slows down threads to let the GC catch up with the work load.
silon42 5y ago
Too bad Java doesn't have an option to disable all runtime type reflection, etc... it would be very similar to Go, I bet. Especially if AOT compiling was used.
throwaway894345 5y ago
Go is "lower level" in the sense that it depends much less on the JVM to optimize things for you. Go code maps much more neatly and predictably to machine code because the optimizations are fewer and less aggressive (e.g., Go has semantics for memory layout). This doesn't imply that Go is inherently faster than Java, but it's easier to reason about the performance of Go code.

Go is at about the same abstraction level as Java, maybe a fraction slower due to lack of runtime VM optimisations.

by melony 5y ago

Go is at about the same abstraction level as Java, maybe a fraction slower due to lack of runtime VM optimisations.

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

Thaxll 5y ago

It's slower or faster but certainly not overall slower. By default Go will be faster because of the difference of value types between the two languages, Go is also easier to optimize since the language is simpler and has less abstraction.

melony 5y ago
Go can be much, much faster if fast compile times is not focus. A good compiler can probably do some compile-time RAII inlining like C++ and Rust and reduce GC usage without needing any major changes to the core Go language. A lot of the more advanced optimizations done by LLVM are not implemented in Go because they slow down compilation. Go compiles insanely quick (like classic Pascal/VB), it feels more like a JITed language than compiled.
- kaba0 5y ago
  > Go compiles insanely quick Compared to Java?
  - throwaway894345 5y ago
    He's implying that it's comparable to Java in that it compiles fast: > it feels more like a JITed language than compiled
  - geodel 5y ago
    Yeah, and one need to compare `go build` with `mvn clean compile/package` not javac. Because Java does not come with inbuilt tools to compile whole projects.
- throwaway894345 5y ago
  Does RAII make code faster? I thought RAII just meant things were freed as soon as they went out of scope rather than waiting for the next GC sweep? Seems like this would make code slower (instead of one free() for all garbage, you have to do a free() for each allocation). Granted, the tracing burden is lower, but I'm of the impression that tracing is cheap?

tomohawk 5y ago

This is not our experience at all. Our experience is that typical Java programs will consume a lot more memory, and spend a lot more time doing GC and other unproductive work than typical Go programs. Go provides a lot more tools that give more bang for the buck when optimizing. For example, everything in Java is a reference to some other distant blob of memory. This does not work well on todays cpus compared to being able to colocate things. We run more stuff on the same machines than we could with Java. Team wise, Go is easier to learn, and scales better with teams. We don't have trouble with team members struggling with certain team member's code / abstractions like we did with Java or C++. Switching between the two, there is a lot more cognitive overhead in Java land. It's understandable that this may be boring to some, but it is a great feature of the language.

kaba0 5y ago
> and spend a lot more time doing GC and other unproductive work than typical Go programs That’s definitely way in the other direction - Java’s GCs run circles around Go’s. (Part of) the reason for Java’s bigger memory consumption is that it is very lazy when it comes to GC. Go runs it all the time for lower latency (at the price of much lower throughput) while Java allows for control it.
- geodel 5y ago
  Java GC has to be very good considering Java could take 10 times more memory for typical data structures compared to memory efficient layouts.
  - kaba0 5y ago
    Not sure if sarcastic, but that has nothing to do with the quality of a GC algorithm. Sure, Java does not (yet) have value types so data structures with non-primitive elements will not have the most optimal layout, but java does objectively have the state of the art GC implementations that work under so high allocation rates that other GCs simply break down. Eg. Go notably slows down threads to let the GC catch up with the work load.

silon42 5y ago

Too bad Java doesn't have an option to disable all runtime type reflection, etc... it would be very similar to Go, I bet. Especially if AOT compiling was used.

throwaway894345 5y ago

Go is "lower level" in the sense that it depends much less on the JVM to optimize things for you. Go code maps much more neatly and predictably to machine code because the optimizations are fewer and less aggressive (e.g., Go has semantics for memory layout). This doesn't imply that Go is inherently faster than Java, but it's easier to reason about the performance of Go code.