←back to thread

175 points nateb2022 | 1 comments | | HN request time: 0.212s | source
Show context
nahuel0x ◴[] No.41522944[source]
Three big differences in comparison with Erlang: 1- Cannot externally kill a process (yes, ergo process have a Kill method but the process will be in a "zombie" state until the current message handlers returns... maybe stuck forever) 2- No hot code reloading. 3- No per-process GC.
replies(4): >>41523113 #>>41523543 #>>41524544 #>>41525115 #
throwaway894345 ◴[] No.41523543[source]
I've never written any Erlang before--why do I care about per-process GC?
replies(5): >>41523595 #>>41523906 #>>41523962 #>>41524224 #>>41527473 #
victorbjorklund ◴[] No.41523906[source]
More consistent performance. No stopping the whole world.
replies(1): >>41524621 #
throwaway894345 ◴[] No.41524621[source]
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?)
replies(2): >>41525191 #>>41529072 #
1. pdimitar ◴[] No.41529072[source]
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.