Hacker News Reader

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. (-:

^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.

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

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.

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

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-p...

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.

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

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.

> 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

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

> There is no reason I can think of that someone would want to be on an older version of Go.

New Go toolchains regularly drop support for running the generated binaries on older versions of Windows and macOS. I definitely want to remain in control of this.

Which you still can as it’s just a default setting.

> That's because they make backwards incompatible changes and release if the unit tests pass.

> At the risk of being downvoted, I have to say that if you don't believe this, you've been Stockholm Syndrome'd into your programming language of choice.

> but if I was trapped on a desert island with node.js I would instantly kill myself.

Too many bold claims to engage with.

It’s tempting to shoot fish in a barrel but you have to try a little harder. ;)

This was a really elegant way to decline having a pointless discussion, I like it.

Idk, I wish they would have actually engaged. No one learns anything new from this reply.

In general people often understand better and prefer the tool they use often to the tool they occasionally have to use but never thought it worthwhile to study in depth.

> I work primarily in Go, but occasionally have to do frontend stuff

Let's get Socratic. How do you address people on the left side of mount-idiot that is the dunning kruger effect?

> I would instantly kill myself.

Strong opinions for "occasionally have to do frontend stuff".

> At the risk of being downvoted

DAE hate package managers and javascript? Updootz plz!

The Reddit playbook is emerging in hacker news which means there was at least “some small exodus”!

More elegant would have been to not reply at all.

We’re both inelegant.

> There is no reason I can think of that someone would want to be on an older version of Go.

Go 1.20 is is the last release that will run on any release of Windows 7, 8, Server 2008 and Server 2012, macOS 10.13 High Sierra or 10.14 Mojave.

In addition to these OSes there are also platforms like Google App Engine. Google is notoriously slow at updating the Go runtime. Until January 17, 2023 the latest Go runtime generally available on Google App Engine was Go 1.16, while in the broader ecosystem Go 1.20 was already scheduled to release two weeks later. That's two whole years behind. It sucks, but it is the reality of how Google operates things. They still haven't added support beyond Go 1.15 to the local development server.

The comment about Node on a desert island made me actually LOL. Thanks for that!

I recently had to update 2 Node (Next.js, static sites) projects from v16 to v18 and it was brutal. Granted it was a big jump but still took over a week to get done. So many dependencies just broke and had to be updated or patched.

Coming from the PHP world, where there is also real effort put into maintaining backwards compatibility, it is really painful. I had sites on version 5.6 that went to version 8 just fine...

> Granted it was a big jump

Node v16: 20 Apr 2021

Node v18: 19 Apr 2022

Are they shipping a major release every six months?! No wonder it’s such a mess.

I'm not sure but one of the challenges we had was the changes to NPM package resolution. We had to use the "legacy peer deps" flag to get certain things to work without upgrading tons of packages.

These were both LTS releases so you would hope that is would be easy to upgrade or at least be able to have a reasonable upgrade path

Not quite. Odd releases EOL with the next release. Even releases are on LTS. https://nodesource.com/blog/understanding-how-node-js-releas...

I run my startup on Go and react. The ease of upgrade process can't be further apart.

We have our entire package.json locked down to the exact patch version because we've had issues where random patch upgrade kills the app, we run our own npm server because we can't trust dependency attacks in the js ecosystem. Just absolute pain.

Ten years of Go, I can count on one hand the times a dependency upgrade broke the build.

> we run our own npm server because we can't trust dependency attacks in the js ecosystem

What does this mean? Your deps get locked down with sha1(?) checksum automatically after you install your packages (unless you go out of your way to delete the lock file). Must be a valuable startup you have for someone to attack your build with a hash collision..

No it's to mitigate "leftpad" style attack vector.

Then don't delete your lock-file and the vector doesn't exist?

Rolling your own package management solution because understanding the existing tools is too hard.. That is peak "javascript sucks and I'm going to comment about it" energy lol.

I'm not fully clear what you mean by don't delete lock file when the problem is the open source developer decides to unpublish their npm package

I think this is more of frontend vs backend thing. I have a similar experience to you with our ~5kloc React frontend, while dependency upgrades for our 50kloc backend have been mostly painless.

We have a service that uses Go http proxy for implementing a reverse proxy.

Upgrading to Go 1.16 introduced an unexplained performance drop. We suspect it is due to how it flushes when the content length is not known (typical for streaming). In earlier versions of Go, the call to flush was less frequent and in other versions, flush was called on every write. As a team, we sunk a lot of time trying to debug this and finally changed some of the application architecture/logic to circumvent these overheads.

And this comes at a cost, having tweaking with Go internals and the compiler I wouldn’t say it’s a mess but it’s a real confusion a lot of things (maybe some) have broken some of the go way, if the go team hadn’t decided to the runtime as a package, 8 years would have taken Go to break changes

Some of it is differences in usecase. If it happens on a dev's laptop, that's... okay, it still rubs me the wrong way, but I get it. If it happens that now every CI job reinstalls the compiler, I'm going to be annoyed.

One workplace I had used GCP. There was a Postgres upgrade and one of our services had a major performance degradation, some people worked for days to mitigate the problem.

Sadly I don’t have the version number or any details as I wasn’t working on the issue. It was sometime in mid 2022.

I know Google does a fair bit of stuff to package Postgres into their CloudSQL offering as a service. It could have possibly been their mistake.

I may be missing something but don’t see how this is pertinent to Go.

jrockway mentions postgres in their comment:

> (While I'm here, I'll also point out that PostgreSQL is similar here. Have you ever upgraded and had your app broke? Absolutely not. Every version is a free performance and feature win.)

I'm all in on Go and enjoy how the toolchain simplifies things so you can just think about writing code. But I am not a fan of this. I don't want my compiler to execute remote code uninstructed.

I don't have extensive experience with Go, but for the bit that I was maintaining a production Go service, I had a Go version update break things at least once.