7 ms·

Good idea! Go has always impressed me on how every single new release works perfectly with zero effort on my part. There is no reason I can think of that some

Good idea! Go has always impressed me on how every single new release works perfectly with zero effort on my part. There is no reason I can think of that someone would want to be on an older version of Go. I understand the objections here. I upgrade software a lot. Upgrade Emacs, your .emacs fails to load. Upgrade Linux, your system fails to boot. That's because they make backwards incompatible changes and release if the unit tests pass. I don't know what Go is doing, but this simply never happens. Every 6 months, you get a performance improvement and new features for free. For free! It's truly amazing. (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.) 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. I work primarily in Go, but occasionally have to do frontend stuff. The pattern that I run into is that if I use the version of Node in Debian, the code doesn't compile. If I go to nodejs.org and download the latest version, it doesn't compile. Only if I install 20000 lines of bash that inspect some files and switches 300 environment variables to put the right version of node.js in my path can I even begin to ... run a script that concatenates 300,000 lines of code and translate it to a version of Javascript that Chrome and Firefox both have? Guys, it's crazy. I love a good user interface, but if I was trapped on a desert island with node.js I would instantly kill myself. No questions asked. Go isn't like that. If your users can handle a CLI, you are one "tar xzvf" way from sanity. It's great. I digressed, but this is a great choice. The Go team always seems to know how to improve the lives of end users. I appreciate that.

c7DJTLrn 3y ago
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.
srcreigh 3y ago
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.
- cdogl 3y ago
  I may be missing something but don’t see how this is pertinent to Go.
  - blcArmadillo 3y ago
    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.)
- Arbortheus 3y ago
  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.
mappu 3y ago
> 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.
- dewey 3y ago
  Which you still can as it’s just a default setting.
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
james2doyle 3y ago
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...
- heartbreak 3y ago
  > 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.
  - james2doyle 3y ago
    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
  - cratermoon 3y ago
    Not quite. Odd releases EOL with the next release. Even releases are on LTS. https://nodesource.com/blog/understanding-how-node-js-release-lines-work/ https://nodesource.com/blog/understanding-how-node-js-releas...
yjftsjthsd-h 3y ago
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.
avgcorrection 3y ago
> 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. ;)
- outime 3y ago
  This was a really elegant way to decline having a pointless discussion, I like it.
  - sapiogram 3y ago
    Idk, I wish they would have actually engaged. No one learns anything new from this reply.
    - 0xParlay 3y ago
      > 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!
      - heyoni 3y ago
        The Reddit playbook is emerging in hacker news which means there was at least “some small exodus”!
    - iudqnolq 3y ago
      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.
deleted 3y ago
[deleted]
Strom 3y ago
> 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.
pxue 3y ago
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.
- 0xParlay 3y ago
  > 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..
  - pxue 3y ago
    No it's to mitigate "leftpad" style attack vector.
    - 0xParlay 3y ago
      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.
      - pxue 3y ago
        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
- sapiogram 3y ago
  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.
mechanicker 3y ago
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.
Patrickmi 3y ago
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
paholg 3y ago
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.

c7DJTLrn 3y ago

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.

srcreigh 3y ago

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.

cdogl 3y ago
I may be missing something but don’t see how this is pertinent to Go.
- blcArmadillo 3y ago
  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.)
Arbortheus 3y ago
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.

mappu 3y ago

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

dewey 3y ago
Which you still can as it’s just a default setting.

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

james2doyle 3y ago

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

heartbreak 3y ago
> 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.
- james2doyle 3y ago
  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
- cratermoon 3y ago
  Not quite. Odd releases EOL with the next release. Even releases are on LTS. https://nodesource.com/blog/understanding-how-node-js-release-lines-work/ https://nodesource.com/blog/understanding-how-node-js-releas...

yjftsjthsd-h 3y ago

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.

avgcorrection 3y ago

> 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. ;)

outime 3y ago
This was a really elegant way to decline having a pointless discussion, I like it.
- sapiogram 3y ago
  Idk, I wish they would have actually engaged. No one learns anything new from this reply.
  - 0xParlay 3y ago
    > 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!
    - heyoni 3y ago
      The Reddit playbook is emerging in hacker news which means there was at least “some small exodus”!
  - iudqnolq 3y ago
    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.

deleted 3y ago

[deleted]

Strom 3y ago

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

pxue 3y ago

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.

0xParlay 3y ago
> 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..
- pxue 3y ago
  No it's to mitigate "leftpad" style attack vector.
  - 0xParlay 3y ago
    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.
    - pxue 3y ago
      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
sapiogram 3y ago
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.

mechanicker 3y ago

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.

Patrickmi 3y ago

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

paholg 3y ago

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.