[donlzx]

Comments are just comments, we should not keep adding keywords and syntax to them.

Go's backward compatible promise is hurting itself. By sticking with strict compatibility mode, ad hoc solutions for fundamental issues are added from time to time. Sooner or later, those patch works will back-fire.

For a language so young (version 1.0 in 2012), they should keep compatibility for stable release (1.x), but start adding language features in 2.x branches ASAP.

Yes, compatibility promise may help selling the Go language at the beginning, but Go authors may seem a little too confident/optimistic of the language spec. in this case. If a 2.x branch is not coming out soon enough (in about two year), we will probably face the same dilemma as Python 2 vs 3.

[Merkur]

One of the best features of go is "go fix" Yea! A migration tool for the language it self? Before they need to worry about compatibility they can break a lot of stuff.

[donlzx]

Yeah I know, we can easily fix the codes with tools, we also have tools for conversion between Python 2 and 3, right?

However, we can not easily fix the way people writing the code, or the so-called idiomatic Go norms.

Actually, it is compatibility in the ecosystem of Go packages that matters. We have lots of good Go packages on Github that are no longer compatible with Go 1.0/1.1/1.2 etc.