Hacker News new | ask | show | jobs
by MCRed 4175 days ago
It's the verbosity that I'm talking about. In go I end up with %70 of my code being error handling or error related... with Elixir it's close to %0.01. I'm giving estimates here, of course, but they aren't off by much. With elixir, using try catch is rare, because it should never crash, and when it does, you lose a process and debug it.

With go, every line that calls a function needs to check to see if there was an error. And handling that error takes at least another line or two.

Unless there's a better way that I'm missing.

1 comments

Ok, verbosity I agree. That doesn't have anything to do with being easy or not, I think. I might be wrong. Verbosity can be a pain. Even after reading Rob Pike's article on "Errors are values" [1], I agree with you that the solution is still verbose.

Those numbers you gave, even when you said they're estimates, still seems like made up numbers. I've never used Elixir, so if you could point me to an example so I can be more informed, I'll be grateful :) but also I've read some Go programs (not many, I'm not an expert) and it didn't seem to me that 70% of the code is dedicated to error handling.

Note that I'm not defending Go's position on error handling, I'm asking about error handling in general, what does people mean with "easy way to do it".

[1]: http://blog.golang.org/errors-are-values

The Erlang/Elixir way can be hard to appreciate because it's not just a very different way of handling errors, it's a completely different way to architect your application. The following tutorial only takes about 45 min to go through, but you'll get a taste for how error handling (across distributed process, at that) works in Elixir: https://howistart.org/posts/elixir/1
I wonder how long it will be until Rob Pike decides that "Handling error values should be enforced by the type system".
here is a podcast where they cite error handling stats of C++ vs Erlang.

http://mostlyerlang.com/2014/11/19/049-supervisors/

starting at 28:45 although you might want to listen to the whole podcast