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.

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

The Go1 promise (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 )

While the above poster didn't explain his problem clearly, it is a valid complaint.

wow, i've been golanging for a year now checking tons of if err != nil and I never once thought there was a problem.

The whole `if err != nil` thing is a different problem as well!

Example of one of them: 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.