3 ms·
As someone who has shipped production software in both Erlang and Go. They are very different beasts. Regarding error handling, Go is far closer to C than Erl
by MetaCosm 13y ago
As someone who has shipped production software in both Erlang and Go. They are very different beasts. Regarding error handling, Go is far closer to C than Erlang. If Erlangs slogan is "let it fail" and gives you the power to avoid writing error handling for every single thing, Go's is "don't let it fail" ... and you really need to write error handlers for everything, reducing the "unexpected" footprint.
There is no real way to grab a goroutine from the outside and tell it what to do -- you have to use its channels, which if bad things have happened are probably broken.. there are some systems built that catch exceptions and send messages (this is from inside the goroutine of course) on the channel, but I haven't used them.
That might come across an unduly negative of Go, but Go has major upsides. Great tooling, easy to understand after a tiny amount of time, a culture of explicit (even at times non-DRY) code, amazing deploy model, and generally just very understandable even to newcomers.
- rdtsc 13y agoInteresting, thank you for explaining. The lack of monitoring of goroutines is certainly different. > which if bad things have happened are probably broken. It reminds me of Joe Armstrong's quote about how it is hard to perform surgery on yourself. In other words having the component that is failing trying to fix itself. I guess I would have to read more about design patterns. I saw a presentation about concurrency patterns in go, but it is about very simple toy examples, I am more interested in a larger concurrent applications, handling multiple connections for example.
- alexk 13y agoI've found net/http package source code to be useful on this matter, as the package contains production-ready servers and clients implemented in Go itself.
- rdtsc 13y agoYes Erlang also has good libraries for that. My question wasn't as much about libraries as about supervision trees. Having a part of your program fail and restarted if needed. For what I understand so far that isn't possible. It would have to be done at the OS process level instead.
- MetaCosm 13y agoYeah... so far my Go stuff has had exceptional reliability, I verified I handled all error known conditions with errcheck (https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck) and just generally took the slow and plodding approach of handling everything explicitly. My app handles hundreds of thousands of concurrent connections, each one often using and/or spawning 4 or more goroutines.
- beefsack 13y agoWhen I'm using Go and have a goroutine which could possibly fail, I also return an error channel allowing the caller to handle errors from inside the goroutine.