5 ms·
Go automatically downloads a newer toolchain if needed
- Sphax 2y agoI like this feature, I used this to be able to use iterators before Go was updated in Homebrew. And yes you need to make sure GOTOOLCHAIN=auto, my colleague had to explicitly set it because it defaults to local on Gentoo.
- Jyaif 2y agoThis sounds amazingly convenient! Language creators, please take note.
- sgt 2y agoImagine if Python 2 automatically upgraded itself to Python 3.
- iand 2y agoImagine if Python had as strong a compatibility promise as Go
- IshKebab 2y agoPython 3 is not backwards compatible with Python 2 so why would it do that? Maybe you meant "imagine if Python 3.6 automatically updated itself to Python 3.12"... Which would be amazing! Except that Python 3.12 is also not backwards compatible with Python 3.6. There's no saving Python.
- pjmlp 2y agoSame is also starting to apply to Go runtime, standard library and even some minor fixes like the for loop variables lifetime. All possible places for existing code to break, either via compiler errors, or changes in the expected runtime semantics.
- IshKebab 2y agoEven in that case they did the behaviour change properly: > To ensure backwards compatibility with existing code, the new semantics will only apply in packages contained in modules that declare go 1.22 or later in their go.mod files. CMake and Rust and Android and lots of other systems have mechanisms like this that allow you to introduce opt-in breaking changes, but unsurprisingly Python doesn't. They just decided it was ok to start breaking backwards compatibility.
- pjmlp 2y agoThat doesn't apply to runtime and standard library changes. Enough of them happened already, that a clarification post was needed, https://go.dev/blog/compat https://go.dev/blog/compat
- IshKebab 2y agoThat's still among the strongest backwards compatibility guarantees in any major language. Maybe Java would be close? It's certainly better than C++ which is famed for backwards compatibility, and light years ahead of Python.
- pjmlp 2y agoYet it isn't without zero issues, as claimed.
- tapirl 2y ago> That's still among the strongest backwards compatibility guarantees in any major language. Not at all. See https://go101.org/blog/2024-03-01-for-loop-semantic-changes-in-go-1.22.html https://go101.org/blog/2024-03-01-for-loop-semantic-changes-... for reasons.
- IshKebab 2y agoWhat reasons? You need to pass one flag to the compiler to specify the language version? That's still very very good. Please tell me what flag I can pass to Python 3.12 so `distutils` still exists.
- trw9991019 2y agoI don't like Python much, but they will definitely not pull off something like this (again), because they've actually learned from that mistake and broadly agree that it was one.
- danslo 2y agoAfter explicitly setting the python version to 3 in package.json? Yes please!
- kokada 2y agoAuthor here. This doesn't make sense. The toolchain will be updated only IF you say your project only runs in Go >= XX. This is what `go` directive in `go.mod` says: my projects doesn't work in versions of Go older than this. This is why it happened to me, I declared I need `go 1.23` because of range-over-func, and the toolchain respected my wishes. This is not an "enforcing you to use the latest Go version, even if you don't wish for it".
- chuckadams 2y agoIt’s more like if virtualenv looked in requirements.txt for the Python version and used that version locally. Other languages like Haskell and Scala have been doing that sort of thing for ages.
- poincaredisk 2y agoI'm not sure I like this feature. I prefer to be in control of the software that runs on my system, without any automated downloads. But I'm a nixos user so...
- Sphax 2y agoSetting the GOTOOLCHAIN environment variable to local disables this. I don't use nix so I'm not sure if they set it by default but you can with set it with `go env`
- srik 2y agoI would've preferred that it be opt out or at least for it to be mentioned prominently enough at some point that it isn't a surprise.
- KingOfCoders 2y agohttps://tip.golang.org/doc/toolchain https://tip.golang.org/doc/toolchain But I guess I was hyper-sensible, because I've missed 'rustup'
- doublerabbit 2y ago> Setting the GOTOOLCHAIN environment variable to local disables this I should be setting the GOTOCHAIN environment variable to enable this, opt-in not opt-out.
- icholy 2y agoWhy? The majority of people are happy with this change.
- doublerabbit 2y agoWhy not opt-in? It forces what the foundation wants you to do. It takes away control from you, it's unethical. Not only that, it opens a can of worms. A compiler should be a compiler. Not an self updating application, nor an dependency modulator from GitHub. How can I trust it when it does all these things? Call me old fashioned at 35. If you want the latest then go download the latest. Is that now to hard for the user? Just because the latest is out doesn't mean it's any better than the previous version. What happens in a CrowdStrike scenario? What happens when Go gets retired in 50 years? I don't want to work with the latest. Should I? TCL 9 is getting there but TCL 8.7 is still perfectly operatable. Should I be using 9 because it exists? My work only has 8.6 on production. So your toolchain updates and they've removed a thing. You've got to hunt down the previous version, let alone needing to discover why it was working yesterday and not today. Unnecessary overhead. You use a dependency that's not updated for the future version? What stops someone from crafting a malicious binary? Malware hijacking the download path? Auto-updating takes away your integrity. Your making blind trust that everything is what it is. How can I be sure that the updated compiler is the compiler and not a malicious crafted version? If you can't trust the compiler how can you trust your code? Yes, I could turn it off, but could I turn it on instead. I shouldn't need to turn it off, I'll update when I want to update tyvm.
- kchr 2y agoI can see the appeal, but hope they keep it opt-in so that people can choose their preferred workflow without surprises.
- olivierduval 2y agoAutomatic updates are always a good idea... until they aren't ! It's an open door to problems ranging from subtle version semantic difference (try to find why what was working yesterday is not working today without any change) to hacking. In corporate environment, it might trigger some unexpected alarms (or be blocked) Gentoo got this right: by default, the "old" behaviour should be kept (no automatic update) and it should only be opt-in
- jackielii 2y agoIt's not automatic though. You explicitly change your go.mod file and then it downloads the toolchains.
- chii 2y agoWhat i'd want is a way to revert back, if the user sees a problem. The automatic updating toolchain is not a bad idea, and in most cases it works great. Once in a while though, there's a fuck up and breaks your build or something changes that you didnt expect. The best way forward is to keep the old tool in a backup location, and have the user be able to revert the update with a single command. Then the user is able to safely return to the old one when the inevitable breakage happens. You could even opt-in to analytics for this action, and the owner of the tool would know if a particular update is a screwup (aka, many people reverted it).
- deleted 2y ago[deleted]
- agwa 2y agoTo be clear, the new toolchain doesn't replace the old toolchain, but is installed alongside it, and is only used for modules that explicitly request the newer toolchain in their go.mod file.
- pjmlp 2y ago> By the way, this only works well because Go binaries are static, one of the things that make the language reasonable good. Only by default, as the Go toolchain supports dynamic linking for ages, and without third party dependencies called via cgo, or stuff like DNS resolution on Linux.
- kokada 2y agoAuthor here. What I meant is that the toolchain itself is linked statically, this is why it can be just downloaded from the internet and it will work without extra setup from the user. Yes, Go will build the libraries once you call `go build`, and yes, they may link to the system C libraries for things like you said. But the `go` binary itself is static.
- sestep 2y agoIf I understand correctly, Rust acts similarly: if you have a `rust-toolchain.toml` file in your repo, any usages of `cargo` will automatically install and use that version of Rust. https://rust-lang.github.io/rustup/overrides.html https://rust-lang.github.io/rustup/overrides.html
- galangalalgol 2y agoYeah, I've run into that and don't love it. Build.rs files are probably a bigger concern from a supply chain attack standpoint.
- cfreksen 2y agoIt seems like that will change in the (near) future according to the following github issue[0]. A quote from one of the developers, rami3l, in that thread[1]: > My current plan is indeed to remove implicit installations entirely. [0]: https://github.com/rust-lang/rustup/issues/3635 https://github.com/rust-lang/rustup/issues/3635 [1]: https://github.com/rust-lang/rustup/issues/3635#issuecomment-2259797014 https://github.com/rust-lang/rustup/issues/3635#issuecomment...
- sestep 2y agoOh sad! Dang I actually really liked the feature, it's super convenient for keeping developer environments in sync. I left a comment in that thread asking for clarification.
- thesuperbigfrog 2y ago>> Oh sad! Dang I actually really liked the feature, it's super convenient for keeping developer environments in sync. I left a comment in that thread asking for clarification. Here is a slightly contrived, but realistic example of why it is a bad idea: 1) Attacker discovers vulnerability in an older version of the Rust toolchain 2) Attacker creates useful crate and helps it to get widely adopted or becomes trusted contributor to a crate that is already popular 3) Attacker creates and publishes crate changes with exploit code and rust-toolchain.toml to trigger use of older, vulnerable Rust toolchain 4) Unsuspecting developers build the trapped crate or something that depends on it and get owned Installing toolchains automatically without the user's consent or permission is a supply chain attack in waiting for both Rust and Go. Perhaps they could make it a configuration setting that developers could opt-in? That would let developers who want automatic toolchain installs to have it and others who do not want it (or whose employers will not allow it) to not have it.
- devsda 2y agoLink to the proposal behind this change: https://go.googlesource.com/proposal/+/master/design/57001-gotoolchain.md https://go.googlesource.com/proposal/+/master/design/57001-g... > Many people believe the go line in the go.mod file specifies which Go toolchain to use. This proposal would correct this widely held misunderstanding by making it reality. That doesn't sound like a good reason to automatically download binaries and run them. Is it difficult to update or install a new version of Go and are there frequent updates in Go spec introducing new features that it is necessary to auto install the compiler itself ? Supply chain attacks are on rise and not a new concept and yet we see these changes. This is not the first time Go lang has introduced a questionable opt-out feature [1]. They backed out but looks like there were no takeaways from that episode. 1. https://news.ycombinator.com/item?id=34771472 https://news.ycombinator.com/item?id=34771472
- trw9991019 2y agoAre you really surprised that people who explicitly refused to learn from 50 years of computer science and software engineering history are refusing to learn from their own mistakes, or even acknowledge them as such? I'll be raising an issue with my distribution of choice to disable this behavior by default. They're the last line of defense for users' security and privacy, and we as an industry have been trying hard to circumvent them. Maybe precisely because of that reason, who knows.
- teeray 2y ago> Is it difficult to update or install a new version of Go Go is the easiest language I know to build from source, let alone run a binary distribution.
- agwa 2y agoThe binaries are fully reproducible from source[1] and are published in a transparency log to provide assurance that your go command is downloading the same binary as every other go command. This is state-of-the-art in preventing supply chain attacks and better than every other language. [1] https://go.dev/rebuild https://go.dev/rebuild
- rjmill 2y ago
- matthartstonge 2y agoYeeeah, this made me lose half a day learning about and then unwinding “toolchain” being accidentally set across all our microservices… Made a little harder to track down initially as we have a replace directive pointing to a local proto module in each service. It was here that toolchain was set which forced it to keep appearing in the top level module. Should’ve been opt in behaviour by default not enforced. We’ve decided to sit on n-1 of Go and I’ve already had an example last month of a well used OSS library setting toolchain to 1.22 as a patch release (which could be considered a breaking change) which fortunately was quickly reverted.
- anotherhue 2y agoBest worst thing about nixos is that none of these terrifying tricks work because the binaries can never find libc.
- evomassiny 2y agoI thought go binaries were purely static, aren't they ?
- cpuguy83 2y agoIf you import net or os then you'll automatically link to libc unless you disable cgo or set the "netgo" and "osusergo" build tag respectively.
- cpuguy83 2y ago... Or do some other flags to statically link to cgo.
- kokada 2y agoAuthor here. You are confusing the `go` toolchain and the binaries generated with Go toolchain. The `go` toolchain itself is compiled statically, this is why this works without issues even in NixOS. Binaries built with the toolchain may or may not be linked against libc depending if you enable or disable CGO. But this is not related to the toolchain, that will work regardless since the toolchain itself is statically compiled. Edit: or in other words, the `go` toolchain is built with CGO disabled.
- kokada 2y agoAuthor here and NixOS user. This works even in NixOS, because `go` toolchain is statically compiled.
- mseepgood 2y agoThe way to look at it: The Go toolchain is just another dependency to your project, declared in go.mod, just like the other modules, and handled accordingly (download, verification etc.)
- seneca 2y agoI'm broadly a Go fan, but this strikes me as a terrible decision. Critical tools should not be working through magic like this. Just fail with a clear error and let the user fix it as they see fit. If they want magic like this, it should be opt-in, not opt-out.
- tapirl 2y agoGoTV does similar things but plays it explicitly: https://go101.org/apps-and-libs/gotv.html https://go101.org/apps-and-libs/gotv.html GoTV builds needed toolchain versions with the Go source code instead of downloading the pre-built toolchain packages.
- igtztorrero 2y agoIt should be optional to activate this feature.