4 ms·
That makes sense, Erlang/Elixir processes are a much higher-level construct than goroutines, and they trade off performance for fault tolerance and observabilit
by ramchip 2y ago
That makes sense, Erlang/Elixir processes are a much higher-level construct than goroutines, and they trade off performance for fault tolerance and observability.
As an example, with a goroutine you have to be careful to handle all errors, because a panic would take down the whole service. In Elixir a websocket handler can crash anywhere without impacting the application. This comes at a cost, because to make this safe Elixir has to isolate the processes so they don't share memory, so each process has its own individual heap, and data gets copied around more often than in Go.
- flakes 2y ago> As an example, with a goroutine you have to be careful to handle all errors, because a panic would take down the whole service. Unless you're the default `net/http` library and simply recover from the panic: https://github.com/golang/go/blob/master/src/net/http/server.go#L1944-L1949 https://github.com/golang/go/blob/master/src/net/http/server...
- neillyons 2y agoYou still need to be careful, as this won't catch panics from go routines launched from your http handler.
- ramchip 2y agoYeah, I'm simplifying a bit. It may not cause an immediate exit, but it can leave the service broken in unpredictable ways. See this discussion for instance: https://iximiuz.com/en/posts/go-http-handlers-panic-and-deadlocks/ https://iximiuz.com/en/posts/go-http-handlers-panic-and-dead...