←back to thread

175 points nateb2022 | 3 comments | | HN request time: 0.653s | 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 #
1. jerf ◴[] No.41527473[source]
You don't. Go is generally significantly faster than Erlang and unless you are deeply concerned about the pauses themselves, you will more than recover GC time in generalized performance in almost all, if not all, cases.

Go's GC already has a lot of work done to minimize "stop the world" time down to very small values.

replies(1): >>41529083 #
2. pdimitar ◴[] No.41529083[source]
As much as I am a fan of Erlang's BEAM VM (and made a career out of Elixir that is still going today) I have to say that you are right -- Golang is doing extremely well and the incremental improvements over the last several years truly pulled it ahead. Unless you're constantly copying big objects and just produce a lot of trash then having your loaded program in Golang is going to be a super smooth sailing. And even if you stumble upon some of the traps, there is a lot of tooling to help you out identify a pain point and remedy it.
replies(1): >>41531478 #
3. jerf ◴[] No.41531478[source]
I am a big believer in the idea that engineers, real professionals, need to have a clear view of what kind of performance technologies deliver, and should never ever view performance statements as a political statement. They may be right or wrong, but they aren't political. This includes both not writing a project that needs very high performance and reaching for a known-lower-performance tool, and also not reaching for the absolutely highest performance tool which generally comes with a price when you are orders of magnitude away from needing it.

Erlang/Elixir has plenty of performance for plenty of problems, but Go is definitely generally a cut above. And there's definitely another cut above Go in performance, it's not the fastest, and there's a cut below Erlang/Elixir as well because they're generally faster than the dynamic scripting languages. And even the dynamic scripting languages are often fast enough for plenty of loads themselves.