Re:The Hidden Complexity of Scaling WebSockets
by flakes on Friday January 24, 2025 @11:08PM
(#42819408)
> 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...
Re:The Hidden Complexity of Scaling WebSockets
by neillyons on Saturday January 25, 2025 @03:31AM
(#42820358)
You still need to be careful, as this won't catch panics from go routines launched from your http handler.
Re:The Hidden Complexity of Scaling WebSockets
by ramchip on Saturday January 25, 2025 @04:06AM
(#42820477)
Yeah, 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-dead...
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.