Except that I'm forced to try/catch on every line that can possibly produce a runtime error.
If you were selling this language to me, how would you explain writing 33% more code to do the same business logic, just to handle errors, over something like Elixir with its rather astonishing uptime and response rate and almost no boilerplate error-handling code? For the backend of an API or webserver, hypothetically.
So I don't know elixir, but but reading up on it the main different seems to be that you can silently ignore errors? You can do the same thing in Go, except it's demarkaed by assigning the error to _. Not sure what the main difference is otherwise?
Any errors crash the node (they are NOT silent, that's the whole point!) and get logged and then restarted by the supervisor node in well under 1 ms. In the event of too many restarts in too short a time, the supervisor is restarted by ITS supervisor (supervision hierarchy). In this way you only have to code the happy path and walk the "known states" while noting frequent sad paths/"unknown states". You can then elect to handle them in your code.
You can still have fatal paths that don't ever get solved, or some large % like that. Running the Go process under something like supervisord would give you the same effect.. it's not clear why this is so different, or why this needs to be at the language level.
Rust uses error values and its error handling is pretty terse (and more type-safe), so this is more of an indictment against go than error values in general.
If you were selling this language to me, how would you explain writing 33% more code to do the same business logic, just to handle errors, over something like Elixir with its rather astonishing uptime and response rate and almost no boilerplate error-handling code? For the backend of an API or webserver, hypothetically.