3 ms·

On the contrary, that you do believe this means that you don't have long enough experience in golang. The points where suddenly a seemingly innocent version up

by JdeBP 3y ago

On the contrary, that you do believe this means that you don't have long enough experience in golang. The points where suddenly a seemingly innocent version upgrade becomes a massive real-world problem usually happen years or decades into a tool/language/whatever. golang hasn't existed nearly long enough yet. "simply never happens" is incorrect. "hasn't happened to me yet" is correct. Or, put another way: Come back to us when you are on version 3.x, years or decades from now, and then a statement that this never happened to you will actually be significant. (-:

jjallen 3y ago
You’re predicting the future which is inherently uncertain. He was talking about the past.
- deleted 3y ago
  [deleted]
- coldtea 3y ago
  Past results are not the whole story, when you see a new signal like a project "changing toolchains on its own" is a new signal that does point to a huge potential future problem. It's like someone saying "Mike? He never hurt nobody! He's a total sweatheart!" when in the past weeks we've seen Mike starting stockpiling guns and getting a "KILL EM ALL!" tattoo on his forehead. OK, perhaps not as dramatic, but changing toolchains behind the users' back, is a red flag for future trouble, even if past behavior was good.
ericpauley 3y ago
^Stockholm Syndrome :) Go is over a decade old. I’ve been using it for 8 or 9 years now and entirely concur with GP. As an example, I have routinely deployed to prod for lower stakes stuff using CI Go versions that didn’t match development. Aside from needing new features this has never caused an issue. I’ve had more issues arise from OS updates than Go toolchain updates.
- TheDong 3y ago
  I've had quite a few issues with go version updates. I've written up a couple over here: https://news.ycombinator.com/item?id=29763324 https://news.ycombinator.com/item?id=29763324 There's more than that. What I really want is to be able to update the compiler without also updating the standard library since the compiler has been fairly solid, while the http, tls, and archive stdlib packages have been a constant source of breaking changes and bugs with each update. I'd rather be able to update my compiler without also having to cross my fingers that they didn't decide to yet again delete support for some part of TLS I'm using that those on high at google have deemed is "insecure", even if it's in a test or over a local network.
  - agwa 3y ago
    Beginning Go 1.21, the version in go.mod will control behavior in the standard library, so that you can upgrade the compiler/stdlib and not have your programs break: https://tip.golang.org/doc/godebug https://tip.golang.org/doc/godebug
Arbortheus 3y ago
Go devs have said there will _never_ be a Go 2 “major” release. They saw the mistakes made by python from 2 to 3 and decided to not do that. It will be backwards compatible 1.x releases forever. https://thenewstack.io/how-golang-evolves-without-breaking-programs/ https://thenewstack.io/how-golang-evolves-without-breaking-p...
- pjmlp 3y ago
  C++, Java and .NET decided otherwise, and I am glad they did, in spite of the adoption pain in some projects. There is no way to improve language if one keeps being dragged by all of the mistakes from the past. Incidently Go might be getting its first breaking change with introduction of new builtins and semantics change on loop variables.
cratermoon 3y ago
> Come back to us when you are on version 3.x, years Someone who has long enough experience in Go would know that the Go compatibility promise[1] only applies to Go 1. Go 2 and later are already allowed to break compatibility. I have code I wrote on something like 1.13, if not earlier and it still works fine with 1.20. Sure, there are rare exceptions, but each release documents them. My question to you, then, is: what exactly did you see in your years of Go experience that broke on a version upgrade? 1 https://go.dev/doc/go1compat#introduction https://go.dev/doc/go1compat#introduction
- pjmlp 3y ago
  Well, the introduction of new built-ins can bring some surprises into existing code that relies on the same names.

by JdeBP 3y ago

jjallen 3y ago

You’re predicting the future which is inherently uncertain. He was talking about the past.

deleted 3y ago
[deleted]
coldtea 3y ago
Past results are not the whole story, when you see a new signal like a project "changing toolchains on its own" is a new signal that does point to a huge potential future problem. It's like someone saying "Mike? He never hurt nobody! He's a total sweatheart!" when in the past weeks we've seen Mike starting stockpiling guns and getting a "KILL EM ALL!" tattoo on his forehead. OK, perhaps not as dramatic, but changing toolchains behind the users' back, is a red flag for future trouble, even if past behavior was good.

ericpauley 3y ago

^Stockholm Syndrome :) Go is over a decade old. I’ve been using it for 8 or 9 years now and entirely concur with GP. As an example, I have routinely deployed to prod for lower stakes stuff using CI Go versions that didn’t match development. Aside from needing new features this has never caused an issue. I’ve had more issues arise from OS updates than Go toolchain updates.

TheDong 3y ago
I've had quite a few issues with go version updates. I've written up a couple over here: https://news.ycombinator.com/item?id=29763324 https://news.ycombinator.com/item?id=29763324 There's more than that. What I really want is to be able to update the compiler without also updating the standard library since the compiler has been fairly solid, while the http, tls, and archive stdlib packages have been a constant source of breaking changes and bugs with each update. I'd rather be able to update my compiler without also having to cross my fingers that they didn't decide to yet again delete support for some part of TLS I'm using that those on high at google have deemed is "insecure", even if it's in a test or over a local network.
- agwa 3y ago
  Beginning Go 1.21, the version in go.mod will control behavior in the standard library, so that you can upgrade the compiler/stdlib and not have your programs break: https://tip.golang.org/doc/godebug https://tip.golang.org/doc/godebug

Arbortheus 3y ago

Go devs have said there will _never_ be a Go 2 “major” release. They saw the mistakes made by python from 2 to 3 and decided to not do that. It will be backwards compatible 1.x releases forever. https://thenewstack.io/how-golang-evolves-without-breaking-programs/ https://thenewstack.io/how-golang-evolves-without-breaking-p...

pjmlp 3y ago
C++, Java and .NET decided otherwise, and I am glad they did, in spite of the adoption pain in some projects. There is no way to improve language if one keeps being dragged by all of the mistakes from the past. Incidently Go might be getting its first breaking change with introduction of new builtins and semantics change on loop variables.

cratermoon 3y ago

> Come back to us when you are on version 3.x, years Someone who has long enough experience in Go would know that the Go compatibility promise[1] only applies to Go 1. Go 2 and later are already allowed to break compatibility. I have code I wrote on something like 1.13, if not earlier and it still works fine with 1.20. Sure, there are rare exceptions, but each release documents them. My question to you, then, is: what exactly did you see in your years of Go experience that broke on a version upgrade? 1 https://go.dev/doc/go1compat#introduction https://go.dev/doc/go1compat#introduction

pjmlp 3y ago
Well, the introduction of new built-ins can bring some surprises into existing code that relies on the same names.