3 ms·

What do you mean?

TheDong 10y ago
The Go1 promise (https://golang.org/doc/go1compat https://golang.org/doc/go1compat) means that they cannot refine the language any further. It's frozen. For example, there's a mess of different error handling techniques (e.g. err == io.EOF vs os.IsNotExist(err) vs perr, ok := err.(*os.PathError); ok). This also prevents the language from evolving, as can be seen in the case of the context package (see 'Frozen' in this post https://github.com/golang/go/issues/14660#issue-138695431 https://github.com/golang/go/issues/14660#issue-138695431 ) While the above poster didn't explain his problem clearly, it is a valid complaint.
- andrewfromx 10y ago
  wow, i've been golanging for a year now checking tons of if err != nil and I never once thought there was a problem.
  - deleted 10y ago
    [deleted]
  - TheDong 10y ago
    The whole `if err != nil` thing is a different problem as well! Example of one of them: https://play.golang.org/p/pku8VJteH1 https://play.golang.org/p/pku8VJteH1 That stupid issue means that packages like os return 'error' even if it will always be of type '*PathError' so you have to be careful to note if the package you're using screwed up in returning err structs or not when doing `if err != nil` or else you'll check a nil interface vs a nil struct... not what you want. This hinders the ability to make richer error types somewhat. In addition, it means you have to always read the docs because the type system cannot represent the possible errors you can get there safely. Second, this is bad because of places in the language (like io.Reader.Read) where it returns two values (numRead, err) where both are useful. Due to the lack of sum types, you can't actually tell in multiple-returns of errors whether the results are mutually exclusive or not. What's more, without sum types, there's no way to express to the type system correctly that you indeed are in a non-nil branch of a value or so on. Finally, there's no macros or other ways in the language to have more expressive error checking than the brain-dead "if err != nil". Sure, what go has is better than java's terrible implementation of exceptions, but it's so much worse than what you get in rust or ocaml or so on.

What do you mean?

The Go1 promise (https://golang.org/doc/go1compat https://golang.org/doc/go1compat) means that they cannot refine the language any further. It's frozen. For example, there's a mess of different error handling techniques (e.g. err == io.EOF vs os.IsNotExist(err) vs perr, ok := err.(*os.PathError); ok). This also prevents the language from evolving, as can be seen in the case of the context package (see 'Frozen' in this post https://github.com/golang/go/issues/14660#issue-138695431 https://github.com/golang/go/issues/14660#issue-138695431 ) While the above poster didn't explain his problem clearly, it is a valid complaint.

andrewfromx 10y ago
wow, i've been golanging for a year now checking tons of if err != nil and I never once thought there was a problem.
- deleted 10y ago
  [deleted]
- TheDong 10y ago
  The whole `if err != nil` thing is a different problem as well! Example of one of them: https://play.golang.org/p/pku8VJteH1 https://play.golang.org/p/pku8VJteH1 That stupid issue means that packages like os return 'error' even if it will always be of type '*PathError' so you have to be careful to note if the package you're using screwed up in returning err structs or not when doing `if err != nil` or else you'll check a nil interface vs a nil struct... not what you want. This hinders the ability to make richer error types somewhat. In addition, it means you have to always read the docs because the type system cannot represent the possible errors you can get there safely. Second, this is bad because of places in the language (like io.Reader.Read) where it returns two values (numRead, err) where both are useful. Due to the lack of sum types, you can't actually tell in multiple-returns of errors whether the results are mutually exclusive or not. What's more, without sum types, there's no way to express to the type system correctly that you indeed are in a non-nil branch of a value or so on. Finally, there's no macros or other ways in the language to have more expressive error checking than the brain-dead "if err != nil". Sure, what go has is better than java's terrible implementation of exceptions, but it's so much worse than what you get in rust or ocaml or so on.