7 ms·

When I first read that, I thought the core conclusions were still mostly correct, but the delta claimed for Rust over Go was too large. Rust will certainly beat

by jerf 5y ago

When I first read that, I thought the core conclusions were still mostly correct, but the delta claimed for Rust over Go was too large. Rust will certainly beat Go on this metric (I expect Rust to even beat C and C++ at scale [1]), but by a factor of 3 is probably on the large side. There are other things that I would consider questionable as well; Haskell might be capable of beating Go if you really, really work at it, but what you might call "casually written Haskell" isn't going to perform anywhere near as well as casually written Go. And the degree of knowledge required to write high-performance Haskell is much higher than high-performance Go. You have to have more than just knowledge of Haskell as a language, you have to have a fairly deep understanding of exactly how GHC compiles and optimizes it. This can be scaled to the Shootout, but scaling it to real code is very difficult. Still, I think the general point is well-taken. I'm less worried about the environmental impact of my code because my code runs at scales where even if my code was running for "free" from an environmental impact, it wouldn't save much of anything. But having used Go for a while, I'd have a really difficult time moving back to a language that is literally dozens of times slower, and, yes, consumes dozens of times more energy as a result. Part of the reason why my code runs at such small scales is that it's reasonably efficient code. I have a couple of services that I consider trivial, but if I were writing them in Python, would be non-trivial. Still not exactly monsters that would be eating clusters of machines at a time, but there's still a lot of practical operational difference between "This occasionally spikes to 25% of a CPU for a minute at high loads" and "This occasionally spikes to consuming 10 full CPUs for a minute at high load", and that's a fairly reasonable multiplier. I have several services that would have deltas like that. [1]: A previous comment of mine: https://news.ycombinator.com/item?id=25625362 https://news.ycombinator.com/item?id=25625362

newaccount2021 5y ago
melony 5y ago
Go is at about the same abstraction level as Java, maybe a fraction slower due to lack of runtime VM optimisations.
- 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
throwaway894345 5y ago
> I have a couple of services that I consider trivial, but if I were writing them in Python, would be non-trivial. I've worked on two large Python projects which would have been trivial in Go. In Python, we had to scale them out to multiple machines and ultimately an Apache Spark cluster (after trying all of the multiprocessing / numpy / Cython / etc gimmicks). The naive Go implementation was a dozen times faster and dramatically more maintainable. Unfortunately our principal engineer couldn't be reasoned with--he understood that in general switching languages isn't a panacea, but he didn't understand the specific problems we were encountering due to Python nor how dramatically Go could improve on them. (He was an inexperienced frontend engineer who was rapidly promoted because he would make shiny demos and hand them off to other teams to fix / extend / operate, and predictably that startup failed).
- zozbot234 5y ago
  > Unfortunately our principal engineer couldn't be reasoned with--he understood that in general switching languages isn't a panacea, but he didn't understand the specific problems we were encountering due to Python nor how dramatically Go could improve on them. It's so interesting that people usually have this complaint about Rust, but here it was a rewrite to Go that was seen as problematic for some reason. Sometimes you just can't win.
  - pdimitar 5y ago
    Rewrites are usually a hard sell. Their benefits are most of the time clear only to those who initiate them. The from/to languages hardly matter to bystanders, sadly.
    - throwaway894345 5y ago
      And in general, rewrites often are a bad idea. But Python is hundreds of times slower than languages like Go and it really doesn't have good levers for improving performance--the "rewrite the slow parts in C / multiprocessing / numpy" promises rarely pan out due to the overhead of pickling / marshaling to efficient C representations. Unfortunately, our principle engineer lacked any mechanical sympathy--he could write JS and Python but had no idea how V8/CPython worked under the hood or how other languages might compare. Ultimately, the more interesting story is how this person was able to "fail upward" so effectively. Basically, nontechnical management don't understand backend software, so the person who makes it "real" for them via user interface demos is the person they associate with manifesting the working feature, even if user interface demos are superficial. Moreover, management only interacted with features by way of his demos, so they didn't understand how much work was required to productionize his demos. The features he debuted would be handed to another team to productionize and support. That team would appear to move slowly as they mired through his tech debt while this principle engineer was moving onto yet another demo, giving the appearance that he was our prolific 10x engineer.
deleted 5y ago
[deleted]

by jerf 5y ago

newaccount2021 5y ago

melony 5y ago

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

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

throwaway894345 5y ago

> I have a couple of services that I consider trivial, but if I were writing them in Python, would be non-trivial. I've worked on two large Python projects which would have been trivial in Go. In Python, we had to scale them out to multiple machines and ultimately an Apache Spark cluster (after trying all of the multiprocessing / numpy / Cython / etc gimmicks). The naive Go implementation was a dozen times faster and dramatically more maintainable. Unfortunately our principal engineer couldn't be reasoned with--he understood that in general switching languages isn't a panacea, but he didn't understand the specific problems we were encountering due to Python nor how dramatically Go could improve on them. (He was an inexperienced frontend engineer who was rapidly promoted because he would make shiny demos and hand them off to other teams to fix / extend / operate, and predictably that startup failed).

zozbot234 5y ago
> Unfortunately our principal engineer couldn't be reasoned with--he understood that in general switching languages isn't a panacea, but he didn't understand the specific problems we were encountering due to Python nor how dramatically Go could improve on them. It's so interesting that people usually have this complaint about Rust, but here it was a rewrite to Go that was seen as problematic for some reason. Sometimes you just can't win.
- pdimitar 5y ago
  Rewrites are usually a hard sell. Their benefits are most of the time clear only to those who initiate them. The from/to languages hardly matter to bystanders, sadly.
  - throwaway894345 5y ago
    And in general, rewrites often are a bad idea. But Python is hundreds of times slower than languages like Go and it really doesn't have good levers for improving performance--the "rewrite the slow parts in C / multiprocessing / numpy" promises rarely pan out due to the overhead of pickling / marshaling to efficient C representations. Unfortunately, our principle engineer lacked any mechanical sympathy--he could write JS and Python but had no idea how V8/CPython worked under the hood or how other languages might compare. Ultimately, the more interesting story is how this person was able to "fail upward" so effectively. Basically, nontechnical management don't understand backend software, so the person who makes it "real" for them via user interface demos is the person they associate with manifesting the working feature, even if user interface demos are superficial. Moreover, management only interacted with features by way of his demos, so they didn't understand how much work was required to productionize his demos. The features he debuted would be handed to another team to productionize and support. That team would appear to move slowly as they mired through his tech debt while this principle engineer was moving onto yet another demo, giving the appearance that he was our prolific 10x engineer.

deleted 5y ago

[deleted]