4 ms·

I'm left wondering why the switch was made in the first place. I spend about half my time coding in Go and love the language, but if I wasn't looking for easier

I'm left wondering why the switch was made in the first place. I spend about half my time coding in Go and love the language, but if I wasn't looking for easier concurrency or a speed boost, I wouldn't re-write an existing code base in Go. It's a lot of work to do just to revert a short time later. The majority of comments are fair, although I'd disagree with it being C2.0 and err != nil getting old - I much prefer it to exceptions.

ben_jones 10y ago
I feel like you can't always handle every error. For instance if you're using a lot of third party libs that you aren't entirely familiar with, you may not be familiar with every possible error a given method call can throw. To complicate the issue error messages are often cryptic, to the point where even if you do catch it it is an entirely pointless exercise. In this situation I feel like try: except Exception as e: is infinitely better then a half-dozen if err != nils.
- JamesMcMinn 10y ago
  Go was essentially designed with the idea that you shouldn't ignore errors. However, if you really don't care about errors, you can simply ignore them: result, _ := thirdparty.ReturnsError()
  - ketralnis 10y ago
    That ignores the error but then silently does the wrong thing when one is thrown. That's different to exceptions where you bail the function instead of proceeding as if nothing went wrong
- clinta 10y ago
  Most of the time I end up writing if err != nil { return nil, err }. This seems better than a simple panic to me it allows the function to return, executing any deferred functions and doing any necessary cleanup. If I had any complaint it would be that go could offer some way to setup default handling that simply returns zero and error for any unhanded errors. I know the same thing can be done with try, catch finally but then you have the same problem of needing to know what errors may be returned so you can make sure an wrap that call in a try statement.
  - madgar 10y ago
    Won't gofmt turn that into 3 lines?
    - clinta 10y ago
      Yes, I just kept it together for brevity.
sanderjd 10y ago
I both prefer error returns to exceptions and find Go's implementation of error returns tedious. There are many other possible implementations that avoid the constant boilerplate. I've seen alternatives that exist in other languages and ideas for a syntax that might make sense in Go elsewhere in this thread, and there are surely others elsewhere.
rdtsc 10y ago
I know of two cases where companies picked Go because it was in the headlines on HN ("we switched from X to Go" stories were pretty common a few years) and also "because Google supports, so it is going to be huge". Now two years later, there is regret and gnashing of teeth. Mostly due to now having to deal with new errors, not everyone knowing Go well enough, destabilized working code. One company loves ease of deployment though -- a single binary. Can't argue against it there.
sickill 10y ago
I updated the blog post with motivations for moving from Python to Go in the first place.

ben_jones 10y ago

I feel like you can't always handle every error. For instance if you're using a lot of third party libs that you aren't entirely familiar with, you may not be familiar with every possible error a given method call can throw. To complicate the issue error messages are often cryptic, to the point where even if you do catch it it is an entirely pointless exercise. In this situation I feel like try: except Exception as e: is infinitely better then a half-dozen if err != nils.

JamesMcMinn 10y ago
Go was essentially designed with the idea that you shouldn't ignore errors. However, if you really don't care about errors, you can simply ignore them: result, _ := thirdparty.ReturnsError()
- ketralnis 10y ago
  That ignores the error but then silently does the wrong thing when one is thrown. That's different to exceptions where you bail the function instead of proceeding as if nothing went wrong
clinta 10y ago
Most of the time I end up writing if err != nil { return nil, err }. This seems better than a simple panic to me it allows the function to return, executing any deferred functions and doing any necessary cleanup. If I had any complaint it would be that go could offer some way to setup default handling that simply returns zero and error for any unhanded errors. I know the same thing can be done with try, catch finally but then you have the same problem of needing to know what errors may be returned so you can make sure an wrap that call in a try statement.
- madgar 10y ago
  Won't gofmt turn that into 3 lines?
  - clinta 10y ago
    Yes, I just kept it together for brevity.

sanderjd 10y ago

I both prefer error returns to exceptions and find Go's implementation of error returns tedious. There are many other possible implementations that avoid the constant boilerplate. I've seen alternatives that exist in other languages and ideas for a syntax that might make sense in Go elsewhere in this thread, and there are surely others elsewhere.

rdtsc 10y ago

I know of two cases where companies picked Go because it was in the headlines on HN ("we switched from X to Go" stories were pretty common a few years) and also "because Google supports, so it is going to be huge". Now two years later, there is regret and gnashing of teeth. Mostly due to now having to deal with new errors, not everyone knowing Go well enough, destabilized working code. One company loves ease of deployment though -- a single binary. Can't argue against it there.

sickill 10y ago

I updated the blog post with motivations for moving from Python to Go in the first place.