6 ms·

I'm cautious about believing this sort of claim because I remember reading about why Go doesn't need generics, yet here we are waiting for Go Generics to be rea

I'm cautious about believing this sort of claim because I remember reading about why Go doesn't need generics, yet here we are waiting for Go Generics to be ready. However, the article convincingly explains who Java has a greater need for a compacting GC - it creates more garbage. This doesn't necessarily mean Go won't benefit from having a generational, compacting GC at some point, for some applications.

runevault 5y ago
Even if it doesn't need specifically a compacting QC having a swappable more tunable one might still be a big deal for people who need something other than the current GC. Like a simple example is the Discord article about how their use case could not work with Go because it always ran the GC every two minutes. If they could optionally disable that feature they theoretically could have kept using Go instead of rewriting to Rust.
- pkaye 5y ago
  You can disable the GC in go. https://pkg.go.dev/runtime/debug#SetGCPercent https://pkg.go.dev/runtime/debug#SetGCPercent
  - kaba0 5y ago
    Also in java, with the Epsilon “GC”. But it is not really meant for programs that have to run for weeks.
- Andys 5y ago
  The go gc was greatly improved in the versions subsequent to the ones used by Discord. The timing there was unfortunate.
  - geodel 5y ago
    Besides sometimes engineers just want to use Rust.
    - drunkenmagician 5y ago
      Ah yes! A new shinny thing. I've had plenty of conversations where some 'new' framework / language solves a 'huge and unsolvable' problem (but that has not actually been deeply investigated), or is just 'cool because XYZ company are using it' ... ¯\_(ツ)_/¯
- lostcolony 5y ago
  That wasn't my read. The Discord team that wrote the article I believe you're referencing ( https://discord.com/blog/why-discord-is-switching-from-go-to-rust https://discord.com/blog/why-discord-is-switching-from-go-to... ) wanted GC, the problem was that they had a huge cache which took a long time for the GC to scan. They could shrink the cache and it would remain performant in the face of GC, but they took latency hits due to increased cache misses. After a bunch of testing and tweaking they found a goldilocks zone where performance was okay. Rust was introduced because it was already something other teams were interested in, and when they tried a quick prototype, they avoided the issue entirely, and saw better performance even in the prototype than their finely tuned Go code, so they switched to it.
  - runevault 5y ago
    To me it sounded like if they could have turned off the auto scan on a time limit it would have been fine because once it was fully up and running they didn't really need GC because the memory footprint was stable. But because they had no way of turning that off without compiling their own version of the runtime it wasn't tenable.
nemo1618 5y ago
> I remember reading about why Go doesn't need generics, yet here we are waiting for Go Generics to be ready Hey, us generics-naysayers are still out here (grumbling)! :)
mohanmcgeek 5y ago
The JVM world right now has quite a few GCs and your choice essentially dictates your program's performance tradeoffs. But I'm not sure if there will ever be a point where this is true for Go considering how little gets into the stack compared to Java.
JulianMorrison 5y ago
Go creates less garbage and also stack allocates things using escape analysis which as the article explains, is effectively a form of generational garbage collection.
- kaba0 5y ago
  As far as I know (I’m not too familiar with Go), Go mostly stack allocates based on the developer’s intent, eg. by using structs. Java doesn’t (yet) have an option for value types that can be reliably stack allocated, so it resorts to very complex escape analysis. Calling the former escape analysis is a bit misleading imo, even if technically true.
  - vore 5y ago
    Go is a little more elaborate than that: if a value is initialized as a pointer-to-struct (e.g. foo := &Foo{...}) and it doesn't escape the function, Go will allocate it as if were a value type.
    - JulianMorrison 5y ago
      You can stack-allocate in C, with alloca() or by taking the address of a local, and use it like a pointer. So long as you're extremely sure nothing is going to hang onto the pointer beyond the lifetime of that stack frame, it's fine. Same thing with Go, except that the compiler makes the decision.
- masklinn 5y ago
  However it's a weak one, the stack allocation acts as a form of extremely limited nursery, but lots of "escaping" objects could well fit into a nursery, to say nothing of "heap" objects (like strings and slices) which always trigger heap allocations. Furthermore AFAIK most generational GCs have 3 generations, not 2 (let alone 1.5). It does make the tradeoff more complicated, a generational GC is not simple (especially in a language with ubiquitous mutability), but the casual dismissals are... troubling. And that's before mentioning the regularly problematic lack of tuning knobs of the Go GC, also often dismissed as "java concerns" (which Go users have to work around using ugly hacks when hit, because they don't have tuning knobs).
socialdemocrat 5y ago
Go designers never said they would never add generics. I've followed Go from the start and they have always been clear that they would consider adding generics if they found a good design for it. However they never had it as a high priority. Many Go fans have said does not need generics, and many including myself would still argue that it doesn't need generics. Yet I cannot say I mind that Go adds generics. I am just worried about whether Go manages to retain its simplicity. Time will tell. I have been a professional Swift programmer who has had ALL the features people have been shouting about for years that Go should have, yet it cannot be said to be a better language. A lot of these features also make Swift more clunky to use than Go in many instances. Having said that, I like both Swift and Go. I just cannot see that more is always more.

runevault 5y ago

Even if it doesn't need specifically a compacting QC having a swappable more tunable one might still be a big deal for people who need something other than the current GC. Like a simple example is the Discord article about how their use case could not work with Go because it always ran the GC every two minutes. If they could optionally disable that feature they theoretically could have kept using Go instead of rewriting to Rust.

pkaye 5y ago
You can disable the GC in go. https://pkg.go.dev/runtime/debug#SetGCPercent https://pkg.go.dev/runtime/debug#SetGCPercent
- kaba0 5y ago
  Also in java, with the Epsilon “GC”. But it is not really meant for programs that have to run for weeks.
Andys 5y ago
The go gc was greatly improved in the versions subsequent to the ones used by Discord. The timing there was unfortunate.
- geodel 5y ago
  Besides sometimes engineers just want to use Rust.
  - drunkenmagician 5y ago
    Ah yes! A new shinny thing. I've had plenty of conversations where some 'new' framework / language solves a 'huge and unsolvable' problem (but that has not actually been deeply investigated), or is just 'cool because XYZ company are using it' ... ¯\_(ツ)_/¯
lostcolony 5y ago
That wasn't my read. The Discord team that wrote the article I believe you're referencing ( https://discord.com/blog/why-discord-is-switching-from-go-to-rust https://discord.com/blog/why-discord-is-switching-from-go-to... ) wanted GC, the problem was that they had a huge cache which took a long time for the GC to scan. They could shrink the cache and it would remain performant in the face of GC, but they took latency hits due to increased cache misses. After a bunch of testing and tweaking they found a goldilocks zone where performance was okay. Rust was introduced because it was already something other teams were interested in, and when they tried a quick prototype, they avoided the issue entirely, and saw better performance even in the prototype than their finely tuned Go code, so they switched to it.
- runevault 5y ago
  To me it sounded like if they could have turned off the auto scan on a time limit it would have been fine because once it was fully up and running they didn't really need GC because the memory footprint was stable. But because they had no way of turning that off without compiling their own version of the runtime it wasn't tenable.

nemo1618 5y ago

> I remember reading about why Go doesn't need generics, yet here we are waiting for Go Generics to be ready Hey, us generics-naysayers are still out here (grumbling)! :)

mohanmcgeek 5y ago

The JVM world right now has quite a few GCs and your choice essentially dictates your program's performance tradeoffs. But I'm not sure if there will ever be a point where this is true for Go considering how little gets into the stack compared to Java.

JulianMorrison 5y ago

Go creates less garbage and also stack allocates things using escape analysis which as the article explains, is effectively a form of generational garbage collection.

kaba0 5y ago
As far as I know (I’m not too familiar with Go), Go mostly stack allocates based on the developer’s intent, eg. by using structs. Java doesn’t (yet) have an option for value types that can be reliably stack allocated, so it resorts to very complex escape analysis. Calling the former escape analysis is a bit misleading imo, even if technically true.
- vore 5y ago
  Go is a little more elaborate than that: if a value is initialized as a pointer-to-struct (e.g. foo := &Foo{...}) and it doesn't escape the function, Go will allocate it as if were a value type.
  - JulianMorrison 5y ago
    You can stack-allocate in C, with alloca() or by taking the address of a local, and use it like a pointer. So long as you're extremely sure nothing is going to hang onto the pointer beyond the lifetime of that stack frame, it's fine. Same thing with Go, except that the compiler makes the decision.
masklinn 5y ago
However it's a weak one, the stack allocation acts as a form of extremely limited nursery, but lots of "escaping" objects could well fit into a nursery, to say nothing of "heap" objects (like strings and slices) which always trigger heap allocations. Furthermore AFAIK most generational GCs have 3 generations, not 2 (let alone 1.5). It does make the tradeoff more complicated, a generational GC is not simple (especially in a language with ubiquitous mutability), but the casual dismissals are... troubling. And that's before mentioning the regularly problematic lack of tuning knobs of the Go GC, also often dismissed as "java concerns" (which Go users have to work around using ugly hacks when hit, because they don't have tuning knobs).

socialdemocrat 5y ago

Go designers never said they would never add generics. I've followed Go from the start and they have always been clear that they would consider adding generics if they found a good design for it. However they never had it as a high priority. Many Go fans have said does not need generics, and many including myself would still argue that it doesn't need generics. Yet I cannot say I mind that Go adds generics. I am just worried about whether Go manages to retain its simplicity. Time will tell. I have been a professional Swift programmer who has had ALL the features people have been shouting about for years that Go should have, yet it cannot be said to be a better language. A lot of these features also make Swift more clunky to use than Go in many instances. Having said that, I like both Swift and Go. I just cannot see that more is always more.