Go 1.17 is deprecating the traditional use of 'go get'

Re:Go 1.17 is deprecating the traditional use of 'go get' by arghnoname on Friday June 25, 2021 @12:17PM (#27632724)

I'd differ on this a bit. Your N+1 scheme is fine with me if you want to use the newest and greatest features, but I think old code / libraries should still work so long as they don't use the latest and greatest features.

I think the compiler should just ship with older versions of the language and different translation units can be compiled with older versions of the compiler. So long as the newer versions can interact with the older ABI (which ideally rarely changes), there's no problem.

[ Parent | on HN ]

Re:Go 1.17 is deprecating the traditional use of 'go get' by bee_rider on Friday June 25, 2021 @01:13PM (#27633597)

In that cast, they'd have to either

* Fix all bugs in old version, or

* Ship known buggy code

Neither seems great. Better to just have archival versions with a "here be dragons" warning.

[ Parent | on HN ]

Re:Go 1.17 is deprecating the traditional use of 'go get' by morelisp on Friday June 25, 2021 @03:23PM (#27635145)

> Ship known buggy code

Thank god there's no known bugs in released software!

[ Parent | on HN ]

Re:Go 1.17 is deprecating the traditional use of 'go get' by bee_rider on Friday June 25, 2021 @04:10PM (#27635643)

I'm not sure I follow.

[ Parent | on HN ]

Re:Go 1.17 is deprecating the traditional use of 'go get' by morelisp on Friday June 25, 2021 @04:18PM (#27635748)

Go 1.17 will release with a lot of known bugs. Continuing to ship it a year later with known bugs is not different.

But more deeply, LTS ships buggy versions of the software. That's the point - only the truly dangerous bugs (e.g. compilation-triggered RCE or something) get fixed, everything else stays compatible even if it's otherwise undesirable or suboptimal. Code depends on those bugs.

[ Parent | on HN ]