4 ms·

This is Go's Python 3 moment. This creates a hard fork of the ecosystem, with a before and after, and all existing Go code is now un-idiomatic and will have to

This is Go's Python 3 moment. This creates a hard fork of the ecosystem, with a before and after, and all existing Go code is now un-idiomatic and will have to be refactored, rewritten, or replaced.

ngrilly 5y ago
Not really. Python 3 introduced breaking changes requiring modification of your code base. That's absolutely not the case here for Go. You can still compile and run your code unchanged. You are also overestimating the magnitude of the number of line of codes impacted by the new style using generics.
- ddevault 5y ago
  It's not a breaking change, but it is a radical change for what it means for Go programs to be Go programs. All Go programs are now written the "wrong" way. Or, in other words: all present Go programs would not pass a code review if they were introduced following the release of Go 2. This also affects many libraries throughout the ecosystem, increasing the API churn and burden on downstream projects. It will create millions of man-hours of work for Go users.
  - pjmlp 5y ago
    They will still compile with a Go 2.0 compiler, try to run a Python 2.7 script on Python 3.9.
  - dpatterbee 5y ago
    Every Go program written using interface{} to provide psuedo-generics was known to be "wrong" at the time it was written, unfortunately the "right" way wasn't a part of the language so people put up with it. I don't believe that generics are going to radically shift any facet of Go programming and I predict that a year from now they'll be just another feature of the language. If somebody's refactoring some area of code that heavily uses interface{} or code generation maybe they'll considered rewriting parts, but interface{} and code generation are not deprecated or made obsolete by generics.
declnz 5y ago
Surely this is more like... when Java 5 introduced Generics, and everything changed a lot (eventually)?

This is Go's Python 3 moment. This creates a hard fork of the ecosystem, with a before and after, and all existing Go code is now un-idiomatic and will have to be refactored, rewritten, or replaced.

ngrilly 5y ago

Not really. Python 3 introduced breaking changes requiring modification of your code base. That's absolutely not the case here for Go. You can still compile and run your code unchanged. You are also overestimating the magnitude of the number of line of codes impacted by the new style using generics.

ddevault 5y ago
It's not a breaking change, but it is a radical change for what it means for Go programs to be Go programs. All Go programs are now written the "wrong" way. Or, in other words: all present Go programs would not pass a code review if they were introduced following the release of Go 2. This also affects many libraries throughout the ecosystem, increasing the API churn and burden on downstream projects. It will create millions of man-hours of work for Go users.
- pjmlp 5y ago
  They will still compile with a Go 2.0 compiler, try to run a Python 2.7 script on Python 3.9.
- dpatterbee 5y ago
  Every Go program written using interface{} to provide psuedo-generics was known to be "wrong" at the time it was written, unfortunately the "right" way wasn't a part of the language so people put up with it. I don't believe that generics are going to radically shift any facet of Go programming and I predict that a year from now they'll be just another feature of the language. If somebody's refactoring some area of code that heavily uses interface{} or code generation maybe they'll considered rewriting parts, but interface{} and code generation are not deprecated or made obsolete by generics.

declnz 5y ago

Surely this is more like... when Java 5 introduced Generics, and everything changed a lot (eventually)?