Hacker News Reader

That makes sense. I wonder how important this is versus Go, considering Go has a sub-millisecond GC even without per-process GC? (Go also makes much more use of the stack which might be sort of analogous to per-process GC?)

View on HN

I have some production experience with Golang and one thing that helps it emulate Erlang's BEAM VM (also used by Elixir, FYI) is to have the goroutines be short-lived and/or disposable. No need for persistent workers most of the time anyway unless you are chasing every last millisecond of performance -- in those cases persistent workers waiting to snatch a job definitely perform better (though only by something like 1-2% in my limited experience; but that can be still a lot depending on hosting and workloads and customer expectations f.ex. in finance forgoing 1-2% perf is almost criminal).

So the BEAM VM definitely handles things a bit better but Golang can get quite close.

This can cause GC to become "bursty."

BeamVM languages complete side step this problem all together.

Out in the field, smoothing out variances can be just as important to overall performance and reliability.

What specifically causes GC to become bursty? Presumably a low latency GC is not "bursty" more or less by definition?

Reply on news.ycombinator.com