9 ms·

For the record, I like Go. I also like Rust. But I really see them as being aimed at different markets. Go is a better Python/Java. Rust is a better C/C++. The

by cletus 7y ago

For the record, I like Go. I also like Rust. But I really see them as being aimed at different markets. Go is a better Python/Java. Rust is a better C/C++. The interesting thing about Go is Rob Pike envisioned it as a systems programming language but any language with GC is a complete nonstarter as a systems programming language. So as for the author's pretext (writing some tool in Go), personally my view is "why not?" not "why not Rust?". If someone had written that same tool in Rust I wouldn't be saying "why not Go?". Whatever floats your boat. But here is the one part where I disagree with the author: > Go is unapologetically simple It is not as simple as it seems, just like every GC language out there. I find Go advocates in particular seem to dismissive of any GC complexities or downsides. Maybe because many of them just don't have the background in dealing with this from years of Java. I worked on a team at Google that wrote and maintained a project using Go. Note that I never wrote anything for this project so my experience was second hand but close second hand. One thing I remember was the Go binary blowing up on memory limits (10GB+) in production. Some debugging found there to be millions of Go channels (IIRC) that needed to be cleaned up. For whatever reason the GC didn't clean them up, possibly because of a non-obvious dangling reference, possibly not. Anything can have bugs obviously. It's just a myth that GC is a silver bullet is my point. There was a guy who worked on the Go team (David Crawshaw) who'd stop by every now and again. Occasionally I'd get into debates with him about Go and GC. It's from these that I established my general observations of Go pundits: 1. Full GC pauses and GC in general are totally not a problem in Go. 2. If they were, they're totally going to be fixed in Go 1.N+1 where N = the current version of Go. (At the time, the argument David made was that Go's STW GC pauses were sub-millisecond so totally not a problem).

AstralStorm 7y ago
And in the meantime Java gets its GC finally fixed to not stall. Yes, it's a real problem, ignoring it for many years costed some people lots of productivity.
sacado2 7y ago
> The interesting thing about Go is Rob Pike envisioned it as a systems programming language but any language with GC is a complete nonstarter as a systems programming language. AFAIK, by "systems programming" he meant "non-user-facing programming", not "kernel or embedded programming". So, basically, servers, batch programs and other os utilities.
- Symmetry 7y ago
  I'd always assumed he was using "systems language" to just mean "as opposed to a scripting language" like perl or bash.
jonathanstrange 7y ago
> any language with GC is a complete nonstarter as a systems programming language If it was possible to write whole operating systems in garbage-collected LISP in the 80s, then it surely is possible to use a GC'ed language for systems programming thirty years later.
- monocasa 7y ago
  If you dig into those machines, anything vaguely real time including huge chunks of the drivers were written in user writable microcode.
  - justin66 7y ago
    Sure, but that's not really a universal indictment of a system or a language. For example, C gets a lot of justifiable criticism, but the ability to drop down to assembly when it's needed is considered a feature and not a bug. The highest-performance gc systems (OCaml?) might very well be associated with functional programming languages, but the more relatable system for a lot of people might be the Oberon system, which did influence Go. I'm pretty certain Oberon did not rely on any hand-coded assembly to build a functioning workstation. (although, on the topic of microcode: the newest Wirth Oberon incarnation does have the student program an FPGA to run the system, as an exercise...)
    - monocasa 7y ago
      Oberon for sure depends on hand coded assembly. It's just in the compiler rather than .asm or .s files, but it's still a big blob of assembly that the type system and GC have no real knowledge of. Right now, state of the art for real time GC is that it's a huge trade-off between throughput and determinism. Like orders of magnitude lower throughput to be able to make guarantees that you'd expect out of a desktop system.
      - justin66 7y ago
        > It's just in the compiler What's your objection to having the compiler emit "hand coded assembly?" It's not clear to me what axe is being ground here. (that's true for me in a big picture way here too. There's a very strong argument against gc languages being made here and I'm not sure if you're saying Oberon doesn't count as a gc language, or what.) > Like orders of magnitude lower throughput to be able to make guarantees that you'd expect out of a desktop system. Do you have a current citation for that?
justin66 7y ago
> any language with GC is a complete nonstarter as a systems programming language As someone else hinted, your rant loses everyone familiar with the history of computing right here. "There were bugs in Go at one time" is not much of an argument against it either.
Crinus 7y ago
> but any language with GC is a complete nonstarter as a systems programming language. Check this out: http://www.projectoberon.com/ http://www.projectoberon.com/ A full system (not just a language, but also custom CPU on FPGA, OS with GUI, applications, etc) where the language is garbage collected. The system has 1MB of RAM (by default). Note that the garbage collector is implemented entirely in the language itself. The Oberon language was also a big inspiration for Go.
pcwalton 7y ago
The issue with Go and garbage collection is basically that Go's GC is just a GC tuned for latency above all else. The GC of Java HotSpot, on the other hand, balances throughput and latency, and is configurable to target one or the other. The latter is typically what applications want, even if it can't advertise the same pause times. For example, allocation is an order of magnitude cheaper in Java HotSpot than it is in Go.
- zeeboo 7y ago
  How do you explain the throughput and latency numbers posted by https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages? Go is beating Java in both latency and throughput, and the author attempted many different Java GC tunings (https://github.com/ixy-languages/ixy-languages/blob/master/Java-garbage-collectors.md https://github.com/ixy-languages/ixy-languages/blob/master/J...) Maybe tuning for latency is the appropriate trade-off given Go's high level of control over allocation and data layout?
  - pjmlp 7y ago
    Because you are mixing up language with implementation. https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/cms/en/JamaicaVM https://www.aicas.com/cms/en/JamaicaVM
    - fwip 7y ago
      Go's a pretty simple language. It should be straightforward (not easy, because compilers aren't easy) for somebody to write another implementation, tuned for another use case - I can't imagine it wouldn't be easier than doing it for Java.
    - zeeboo 7y ago
      You're jumping to conclusions. I understand the distinction and that there are many options for Java. Please be charitable. To rephrase the question more precisely: can you explain why OpenJDK, which has a multitude of garbage collector implementations tuned for both throughput and latency, performs worse on both throughput and latency than Go on this benchmark which has a garbage collector that, according to the original statement, is "tuned for latency above all else"? Perhaps OpenJDK is problematic in other ways (the author of the benchmarks suspects it's JIT induced, even though that's attempted to be controlled for), or perhaps this test depends less on the GC for some reason. Or maybe typical Go programs don't require as many allocations making allocation time much less important making tuning for latency the correct engineering decision. Would HotSpot do significantly better as is claimed? That's the sort of interesting technical discussion I'd like to have, instead of pedantry.
zeeboo 7y ago
The memory leak due to channels not being cleaned up was almost certainly because goroutines themselves are not garbage collected when they're forever blocked. In other words, `ch := make(chan int); go func() { ch <- 1 }()` is a memory leak. This is analogous to spawning a thread that deadlocks by attempting to lock a mutex twice, and has nothing to do with garbage collection. About the GC pauses, check out the latency graphs at https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages (being careful not to mix up the Javascript and Go lines). Go handily beat every other garbage collected language in latency, and is in the same ballpark as the two non-GC languages (Rust and C). The peak tail latency times are measured in the hundreds of microseconds even at the highest loads tested, so I think the pundits may have a point.
- hinkley 7y ago
  Sounds very similar to "leaking" event listeners in other languages. The handler and all of the scope it can reach stick around forever even though they should have been replaced or removed.
- pcwalton 7y ago
  GC is more than just pauses. Throughput matters too; in fact, it often matters more than latency (for example, when writing batch jobs like compilers).
  - zeeboo 7y ago
    Sure, but that's not relevant to the discussion here. In this case the context was responding to the the statements that Go pundits claim the garbage collector has low latency but it always has bugs that will be fixed in the next version. I was providing evidence that the garbage collector actually does achieve low latency right now. Also, there are ways to solve your throughput problems if you have control over your allocations, but there are not ways to solve your latency problems. Indeed, even if you don't have control of your allocations, you can often run multiple copies of your program to increase your throughput, but multiple copies will not help your latency. Also, tuning your latency does in fact help increase throughput, because if your process spends a significant amount of time in allocations, its latency suffers. It's not a zero-sum knob between the two, especially in the presence of humans that care about tuning the performance of their applications.

by cletus 7y ago

AstralStorm 7y ago

And in the meantime Java gets its GC finally fixed to not stall. Yes, it's a real problem, ignoring it for many years costed some people lots of productivity.

sacado2 7y ago

> The interesting thing about Go is Rob Pike envisioned it as a systems programming language but any language with GC is a complete nonstarter as a systems programming language. AFAIK, by "systems programming" he meant "non-user-facing programming", not "kernel or embedded programming". So, basically, servers, batch programs and other os utilities.

Symmetry 7y ago
I'd always assumed he was using "systems language" to just mean "as opposed to a scripting language" like perl or bash.

jonathanstrange 7y ago

> any language with GC is a complete nonstarter as a systems programming language If it was possible to write whole operating systems in garbage-collected LISP in the 80s, then it surely is possible to use a GC'ed language for systems programming thirty years later.

monocasa 7y ago
If you dig into those machines, anything vaguely real time including huge chunks of the drivers were written in user writable microcode.
- justin66 7y ago
  Sure, but that's not really a universal indictment of a system or a language. For example, C gets a lot of justifiable criticism, but the ability to drop down to assembly when it's needed is considered a feature and not a bug. The highest-performance gc systems (OCaml?) might very well be associated with functional programming languages, but the more relatable system for a lot of people might be the Oberon system, which did influence Go. I'm pretty certain Oberon did not rely on any hand-coded assembly to build a functioning workstation. (although, on the topic of microcode: the newest Wirth Oberon incarnation does have the student program an FPGA to run the system, as an exercise...)
  - monocasa 7y ago
    Oberon for sure depends on hand coded assembly. It's just in the compiler rather than .asm or .s files, but it's still a big blob of assembly that the type system and GC have no real knowledge of. Right now, state of the art for real time GC is that it's a huge trade-off between throughput and determinism. Like orders of magnitude lower throughput to be able to make guarantees that you'd expect out of a desktop system.
    - justin66 7y ago
      > It's just in the compiler What's your objection to having the compiler emit "hand coded assembly?" It's not clear to me what axe is being ground here. (that's true for me in a big picture way here too. There's a very strong argument against gc languages being made here and I'm not sure if you're saying Oberon doesn't count as a gc language, or what.) > Like orders of magnitude lower throughput to be able to make guarantees that you'd expect out of a desktop system. Do you have a current citation for that?

justin66 7y ago

> any language with GC is a complete nonstarter as a systems programming language As someone else hinted, your rant loses everyone familiar with the history of computing right here. "There were bugs in Go at one time" is not much of an argument against it either.

Crinus 7y ago

> but any language with GC is a complete nonstarter as a systems programming language. Check this out: http://www.projectoberon.com/ http://www.projectoberon.com/ A full system (not just a language, but also custom CPU on FPGA, OS with GUI, applications, etc) where the language is garbage collected. The system has 1MB of RAM (by default). Note that the garbage collector is implemented entirely in the language itself. The Oberon language was also a big inspiration for Go.

pcwalton 7y ago

The issue with Go and garbage collection is basically that Go's GC is just a GC tuned for latency above all else. The GC of Java HotSpot, on the other hand, balances throughput and latency, and is configurable to target one or the other. The latter is typically what applications want, even if it can't advertise the same pause times. For example, allocation is an order of magnitude cheaper in Java HotSpot than it is in Go.

zeeboo 7y ago
How do you explain the throughput and latency numbers posted by https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages? Go is beating Java in both latency and throughput, and the author attempted many different Java GC tunings (https://github.com/ixy-languages/ixy-languages/blob/master/Java-garbage-collectors.md https://github.com/ixy-languages/ixy-languages/blob/master/J...) Maybe tuning for latency is the appropriate trade-off given Go's high level of control over allocation and data layout?
- pjmlp 7y ago
  Because you are mixing up language with implementation. https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/cms/en/JamaicaVM https://www.aicas.com/cms/en/JamaicaVM
  - fwip 7y ago
    Go's a pretty simple language. It should be straightforward (not easy, because compilers aren't easy) for somebody to write another implementation, tuned for another use case - I can't imagine it wouldn't be easier than doing it for Java.
  - zeeboo 7y ago
    You're jumping to conclusions. I understand the distinction and that there are many options for Java. Please be charitable. To rephrase the question more precisely: can you explain why OpenJDK, which has a multitude of garbage collector implementations tuned for both throughput and latency, performs worse on both throughput and latency than Go on this benchmark which has a garbage collector that, according to the original statement, is "tuned for latency above all else"? Perhaps OpenJDK is problematic in other ways (the author of the benchmarks suspects it's JIT induced, even though that's attempted to be controlled for), or perhaps this test depends less on the GC for some reason. Or maybe typical Go programs don't require as many allocations making allocation time much less important making tuning for latency the correct engineering decision. Would HotSpot do significantly better as is claimed? That's the sort of interesting technical discussion I'd like to have, instead of pedantry.

zeeboo 7y ago

The memory leak due to channels not being cleaned up was almost certainly because goroutines themselves are not garbage collected when they're forever blocked. In other words, `ch := make(chan int); go func() { ch <- 1 }()` is a memory leak. This is analogous to spawning a thread that deadlocks by attempting to lock a mutex twice, and has nothing to do with garbage collection. About the GC pauses, check out the latency graphs at https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages (being careful not to mix up the Javascript and Go lines). Go handily beat every other garbage collected language in latency, and is in the same ballpark as the two non-GC languages (Rust and C). The peak tail latency times are measured in the hundreds of microseconds even at the highest loads tested, so I think the pundits may have a point.

hinkley 7y ago
Sounds very similar to "leaking" event listeners in other languages. The handler and all of the scope it can reach stick around forever even though they should have been replaced or removed.
pcwalton 7y ago
GC is more than just pauses. Throughput matters too; in fact, it often matters more than latency (for example, when writing batch jobs like compilers).
- zeeboo 7y ago
  Sure, but that's not relevant to the discussion here. In this case the context was responding to the the statements that Go pundits claim the garbage collector has low latency but it always has bugs that will be fixed in the next version. I was providing evidence that the garbage collector actually does achieve low latency right now. Also, there are ways to solve your throughput problems if you have control over your allocations, but there are not ways to solve your latency problems. Indeed, even if you don't have control of your allocations, you can often run multiple copies of your program to increase your throughput, but multiple copies will not help your latency. Also, tuning your latency does in fact help increase throughput, because if your process spends a significant amount of time in allocations, its latency suffers. It's not a zero-sum knob between the two, especially in the presence of humans that care about tuning the performance of their applications.