Go has the Green Tea GC since 1.25. It’s no longer simplistic and quite well engineered. The AVX-512 support was especially interesting to me.

https://go.dev/blog/greenteagc

I've run into GC pauses, I think in many (most?) cases there is some class of bulky data that you can either move into slices of pointer-free structs (so the GC doesn't scan them) or off-heap entirely. The workload where GC is slow is also likely prone to fragmentation so whatever the language you'll have to deal with it.

> For me the main advantage of Go over Rust is compilation speed.

Interestingly, Rust has quite good failed compilation speed. That's almost good enough. The usual Rust experience is that it's hard to get things to compile, and then they work the first time.

What kind of apps are you writing where GC spikes matter?

Rust compilation speed is a matter of tooling, they could have something like OCaml or Haskell interpreters, which so far hasn't been a priority.

Or having Cranelift as default backend.

if you are hitting pauses due to GC issues, you should into putting appropriate data structures into a memory arena, here's a reasonable read:

https://uptrace.dev/blog/golang-memory-arena

These are all tools. Java used to have this all the time, and we (ex-java programmer) had ways around this until the JVM improved.

Isn’t it somewhat easy to remove allocations in Go? I haven’t had to “rewrite” as such, but rather lifting some allocation out of loop. Am I misunderstanding the scenario?

> Rust still rely on many C and C++ libraries

Yes but Rust has a lot more availability of libraries to do stuff as a result. Want to do anything ML or scientific? You at least have a route in Rust where you don’t with Go.