> It doesn't matter to me that Erlang's GC is hypothetically faster because of its actor model when Go is just straight-up so much faster across the board that it doesn't matter.
> Whether a fully compiled language could recover this I don't know, but I doubt there's any room in 2022 to spank a modern GC by more than a few percent as a result of this. By the time you're getting to the scale where this is a problem, everything's a problem anyhow.
It's still relevant if you need consistency. Any GC language eventually has to defragment the heap, and any pervasive-shared-mutability language pretty much has to stop the world to do so. For all that Go is a high throughput language (something that's overstated IME), it's not suitable for realtime, and Erlang is.
> Whether a fully compiled language could recover this I don't know, but I doubt there's any room in 2022 to spank a modern GC by more than a few percent as a result of this. By the time you're getting to the scale where this is a problem, everything's a problem anyhow.
It's still relevant if you need consistency. Any GC language eventually has to defragment the heap, and any pervasive-shared-mutability language pretty much has to stop the world to do so. For all that Go is a high throughput language (something that's overstated IME), it's not suitable for realtime, and Erlang is.