23 ms·

oh there were plenty other reasons before this!

• pjmlp 10y ago
  I used to think like that until they decided to freeze the language.
  • federicoponzi 10y ago
    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.
  • remus 10y ago
    It isn't a language freeze but a comparability promise. "It is intended that programs written to the Go 1 specification will continue to compile and run correctly, unchanged, over the lifetime of that specification. At some indefinite point, a Go 2 specification may arise, but until that time, Go programs that work today should continue to work even as future "point" releases of Go 1 arise (Go 1.1, Go 1.2, etc.)." Granted that means it is effectively a freeze on backwards incompatible changes, but it does leave the door open for additions to the language. Having said that, the go authors are definitely very conservative with language changes.
    • pjmlp 10y ago
      No, frozen are the words used by the Go team. "Not everything was fixed, though. We're still learning (but the language is frozen for now). " https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article