5 ms·

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

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.

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.