3 ms·

> Not enough Go code adds context like os.Remove does. Too much code does only if err != nil { return err } Is anyone else surprised that forcing

by stouset 10y ago

> Not enough Go code adds context like os.Remove does. Too much code does only if err != nil { return err } Is anyone else surprised that forcing programmers to do the tedious, repetitive, and boring work of being a manual exception handler overwhelmingly results in people doing the least amount of effort to make it work? I feel like so many of the headaches of go could have been avoided had the developers spent any time whatsoever thinking about the programmers using it.

tombert 10y ago
I think that the Go team worked very hard to make something that programmers actually like using. Yes, it is annoying to do a lot of `check if err is nil`, but at the same time, exception handling is something that can be esoteric, whilst it's trivial to see what your example does. I also feel like there has been a lot of emphasis put on keeping the APIs consistent, which is something that a lot of developers will tell you makes PHP a nightmare sometimes.
- stouset 10y ago
  > Yes, it is annoying to do a lot of `check if err is nil`, but at the same time, exception handling is something that can be esoteric People keep saying this, but the alternative doesn't have to be exceptions. Rust strikes a great balance here. There's no nil, you must handle the Err case of a Result enum, or the None case of an Option enum (this is much nicer than go; in go after `val, err := failingThing()`, it's entirely possible to accidentally use `val` as a meaningful value, which is strictly impossible in Rust), and you can use functions like `map` and `and_then` on these types which has the benefits of explicit error handling without the absurd loss of readability caused by dozens of identical error handling clauses. > I also feel like there has been a lot of emphasis put on keeping the APIs consistent This isn't something special about go. This is a minimum requirement for a language nowadays. Rust, Ruby, Python, Swift, and others all do this.

by stouset 10y ago

tombert 10y ago

I think that the Go team worked very hard to make something that programmers actually like using. Yes, it is annoying to do a lot of `check if err is nil`, but at the same time, exception handling is something that can be esoteric, whilst it's trivial to see what your example does. I also feel like there has been a lot of emphasis put on keeping the APIs consistent, which is something that a lot of developers will tell you makes PHP a nightmare sometimes.

stouset 10y ago
> Yes, it is annoying to do a lot of `check if err is nil`, but at the same time, exception handling is something that can be esoteric People keep saying this, but the alternative doesn't have to be exceptions. Rust strikes a great balance here. There's no nil, you must handle the Err case of a Result enum, or the None case of an Option enum (this is much nicer than go; in go after `val, err := failingThing()`, it's entirely possible to accidentally use `val` as a meaningful value, which is strictly impossible in Rust), and you can use functions like `map` and `and_then` on these types which has the benefits of explicit error handling without the absurd loss of readability caused by dozens of identical error handling clauses. > I also feel like there has been a lot of emphasis put on keeping the APIs consistent This isn't something special about go. This is a minimum requirement for a language nowadays. Rust, Ruby, Python, Swift, and others all do this.