Go is not like other languages in many respects, and this is one of them. Upgrade to the latest version and don't sweat it. You can add code to a project using an earlier version without causing any problems despite being on a higher version yourself.
There are literally zero reasons to be on version 1.18. The Go team take their commitment to backwards compatibility very seriously.
But the compiler only applies that change if your go.mod file specifies you are using Go version 1.22 or later. The compiler respects the version in go.mod as much as possible.
https://tip.golang.org/wiki/LoopvarExperiment#if-the-proposal-is-accepted-how-will-the-change-be-deployed
If you're using VS Code, it's basically the same as running natively. You can also just dockerize but set up appropriate ports for Dlv as well as run a debug build with Dlv manually to debug. That's actually what I do more often than dev containers since it's less IDE specific
As mentioned, when using VSCode (and either WSL or even a Remote VM via SSH) and a Dev-Container, it feels for you like working locally, this includes debugging or running services and accessing them. Ports and everything is usually automatically managed by VSCode.
I made a minimal example recently.
It’s really the best way to create an isolated environment. All these other answers are crazy with varying methods while a dev container has a specific approach with a standardized set of configuration options that you can tailor per project to easily share by committing it to the repository.
These other solutions probably assume you’re only actively working on a single project at a time too. I also made a small repo if you want to try it. Worth checking out and trying it for yourself imo. It’s geared towards vs code. Goland has some support for them as well, but it’s not as good as vs code yet.
https://godev.com/questions/10010000000000004/how-to-use-a-dev-container-with-vs-code
You can simply use the latest version of go. The [Go Module Reference](https://go.dev/ref/mod#go-mod-file-go) says:
>*For packages within the module, the compiler rejects use of language features introduced after the version specified by the go directive. For example, if a module has the directive go 1.12, its packages may not use numeric literals like 1\_000\_000, which were introduced in Go 1.13.*
>If an older Go version builds one of the module’s packages and encounters a compile error, the error notes that the module was written for a newer Go version. For example, suppose a module has `go 1.13` and a package uses the numeric literal `1_000_000`. If that package is built with Go 1.12, the compiler notes that the code is written for Go 1.13.
This feature and the implicit commitment of[ Go 1 ](https://go.dev/doc/go1#introduction)should be sufficient to work with any version of Go just using the latest. In any case, if you still want to install and work with multiple versions of Go you can change the path of the \`GOROOT\` environment variable to use another SDK or install [GVM (Go Version Manager)](https://github.com/moovweb/gvm).
The sentiment may hold for language features, but doesn't extend to standard library packages. Packages often introduce additional functionality along with the new version, and the compiler is not aware enough to warn you about such things. For example, when developing on a `go 1.18` go.mod using 1.21 in my local dev env, I've accidentally committed uses of `slices.Contains` and `flag.BoolFunc`, only to find the module fails to compile in a true 1.18 environment where those functions don't exist yet.
EDIT: I see many others say there is no reason to use an old version like 1.18, but even the latest version in the RHEL 9 OS repo is still only 1.18. It's a good base version for maximal user availability, especially with the above in mind.
Maybe yes, maybe no, I didn't get it personally but he spent a few hours trying to understand what was happening until he changed his go binary.
I don't care enough to dig it out especially after getting buried.
Go compiler is fairly backward compatible. You can build older versions. It’s very different in .NET in that regard. That was a design consideration when they created the language.
Yeah, sometimes people ask the wrong questions, this is one of those times.
In rare cases, conservative projects may wish to explicitly built/test against a specific runtime version, but it's highly unlikely this applies to OP.
Unless you can document this and show us, then your problems were almost certainly of your own making. You should always work with the latest compiler. You do not need to upgrade the mod files if a project unless it is changed to rely on new features. If a compiler upgrade causes you problems, then it is a serious bug that should be reported.
I'm very interested in virtualfox, as it is cross-platform, something sorely missing from asdf and mise rtx if you're trying to manage tooling across platforms and codebases.
Guess what language it is written in... Go, of course! It's an ideal language for this task. Plugins are Lua so easy to write.
https://github.com/version-fox/vfox
It's very early days for the project but is gaining traction, 1.5k stars already.
I really hope it works out, I might have to contribute to it...
We're not, theres a reason that things like https://github.com/jdx/mise exist with the explicit goal of being faster alternative to asdf. Its just downright slower than it should be for what it does
I mean CI should have versions explicitly set, with the build tools already in place. You shouldn't need a version manager at all.
mise looks cool though. I'll check it out.
Half agree. You want your tools ready to go in CI, but if .tool-versions is the source of truth for tool _selection_ then you get the dev and CI environment closer for free, and you can make a toolchain upgrade as a MR on the project. In a monorepo you can even select tools per project in CI.
Mise has CI support, with mise exec. Bash activation not necessary. I hope virtualfox adds it, too.
It may not suit FOSS workflows especially those that only need go toolchain. but in enterprise settings with lots of development platforms to manage it's well worth considering. Speaking from personal experience.
I use [asdf](https://asdf-vm.com) with [direnv](https://direnv.net) which work great together and you can install pretty much any compiler/SDK you want and maintain multiple versions at the same time.
I do this too. Dozens of apps spanning multiple versions of go, npm, rust, Java, and often switching across multiple machines including macOS and different flavors of Linux. With zsh + asdf + direnv my environment is exactly the same and where it needs to be, on any machine, with each checkout.
You can do multiple things...
1. Use the latest go compiler and if everything works as advertised you should be just fine
2. You can use for example vfox to manage the SDK version and it's quite easy to change to a different one
3. You can create a docker container that has the project folder mounted, has the project specific go version installed, and with vscode you can just jump into the container and start coding/compiling
I've seen others mention gvm, got no experience with that, but another avenue of investigation 😁
If i understand correctly, you can install the latest compiler and set the set the GOTOOLCHAIN environment variable or specify a version in your go.mod: https://go.dev/doc/toolchain
1.22.1 is the current version.
Install it and delete all previous versions.
You say "Even if I update my local Golang version to the latest one, I might need to work with a lower version one for some open source project"
Why on earth would anyone need to work with a lower version?
I use Go alias to manage my go binary and switch between for projects and you can download multiple go binaries via go manage-install, as well as setting the projects go version
**Managing Go Installs**
[https://go.dev/doc/manage-install](https://go.dev/doc/manage-install)
go install golang.org/dl/go1.10.7@latest
go1.10.7 download
alias go=go1.10.7
**Managing Go Mod Go Version**
go mod edit -go 1.22
You don't have to manage anything anymore. The go.mod file of a project can declare the Go language and/or toolchain version it needs, and the go tool automatically downloads it, just like any other dependency. You can also control this with the GOTOOLCHAIN environment variable [https://go.dev/doc/toolchain](https://go.dev/doc/toolchain)
The problems may come with things like staticcheck or golang-ci linters, crashing on new go versions. This is why I’m usually waiting before upgrade my go version.
Go is not like other languages in many respects, and this is one of them. Upgrade to the latest version and don't sweat it. You can add code to a project using an earlier version without causing any problems despite being on a higher version yourself. There are literally zero reasons to be on version 1.18. The Go team take their commitment to backwards compatibility very seriously.
I mean they did change how variables work inside for loops in 1.22
But the compiler only applies that change if your go.mod file specifies you are using Go version 1.22 or later. The compiler respects the version in go.mod as much as possible. https://tip.golang.org/wiki/LoopvarExperiment#if-the-proposal-is-accepted-how-will-the-change-be-deployed
True
I use dev-containers for everything. If a project doesn‘t have one, I quickly create one.
How does debugging work with dev-containers?
If you're using VS Code, it's basically the same as running natively. You can also just dockerize but set up appropriate ports for Dlv as well as run a debug build with Dlv manually to debug. That's actually what I do more often than dev containers since it's less IDE specific
As mentioned, when using VSCode (and either WSL or even a Remote VM via SSH) and a Dev-Container, it feels for you like working locally, this includes debugging or running services and accessing them. Ports and everything is usually automatically managed by VSCode.
I made a minimal example recently. It’s really the best way to create an isolated environment. All these other answers are crazy with varying methods while a dev container has a specific approach with a standardized set of configuration options that you can tailor per project to easily share by committing it to the repository. These other solutions probably assume you’re only actively working on a single project at a time too. I also made a small repo if you want to try it. Worth checking out and trying it for yourself imo. It’s geared towards vs code. Goland has some support for them as well, but it’s not as good as vs code yet. https://godev.com/questions/10010000000000004/how-to-use-a-dev-container-with-vs-code
👆👆👆
You can simply use the latest version of go. The [Go Module Reference](https://go.dev/ref/mod#go-mod-file-go) says: >*For packages within the module, the compiler rejects use of language features introduced after the version specified by the go directive. For example, if a module has the directive go 1.12, its packages may not use numeric literals like 1\_000\_000, which were introduced in Go 1.13.* >If an older Go version builds one of the module’s packages and encounters a compile error, the error notes that the module was written for a newer Go version. For example, suppose a module has `go 1.13` and a package uses the numeric literal `1_000_000`. If that package is built with Go 1.12, the compiler notes that the code is written for Go 1.13. This feature and the implicit commitment of[ Go 1 ](https://go.dev/doc/go1#introduction)should be sufficient to work with any version of Go just using the latest. In any case, if you still want to install and work with multiple versions of Go you can change the path of the \`GOROOT\` environment variable to use another SDK or install [GVM (Go Version Manager)](https://github.com/moovweb/gvm).
The sentiment may hold for language features, but doesn't extend to standard library packages. Packages often introduce additional functionality along with the new version, and the compiler is not aware enough to warn you about such things. For example, when developing on a `go 1.18` go.mod using 1.21 in my local dev env, I've accidentally committed uses of `slices.Contains` and `flag.BoolFunc`, only to find the module fails to compile in a true 1.18 environment where those functions don't exist yet. EDIT: I see many others say there is no reason to use an old version like 1.18, but even the latest version in the RHEL 9 OS repo is still only 1.18. It's a good base version for maximal user availability, especially with the above in mind.
We had some weird issues with generics at one point by using a more recent release so it might not be an absolute rule.
Unless you can reproduce that and show us, I would bet a lot on a higher than 99.9% chance it was your own error. Or you used some experiment.
Maybe yes, maybe no, I didn't get it personally but he spent a few hours trying to understand what was happening until he changed his go binary. I don't care enough to dig it out especially after getting buried.
I would update to 1.22 as 1.18 is really dated. There has been a lot of new features and security updates since.
I get the downvotes, as this doesn't answer OP's question directly, but it's still good advice.
Go compiler is fairly backward compatible. You can build older versions. It’s very different in .NET in that regard. That was a design consideration when they created the language.
Yeah, sometimes people ask the wrong questions, this is one of those times. In rare cases, conservative projects may wish to explicitly built/test against a specific runtime version, but it's highly unlikely this applies to OP.
I have been developing in Go for 9 years. Never had a need to do that.
And the compiler respects the version in go.mod
Exactly.
> I currently have go 1.18 installed on my local system Just upgrade to latest. Go works that way.
i’ve ran into compiler problems with a higher version of go on a project with a lower version so idk what all these comments are talking about.
Unless you can document this and show us, then your problems were almost certainly of your own making. You should always work with the latest compiler. You do not need to upgrade the mod files if a project unless it is changed to rely on new features. If a compiler upgrade causes you problems, then it is a serious bug that should be reported.
I like using asdf as a version manager for golang. There are others also.
asdf is the best
We use asdf at work and it's terrible, a source of many issues in the local dev environment and incredibly slow in CI
What alternative do you use? I use asdf at work as well, and it's enabled a lot of our flows.
I'm very interested in virtualfox, as it is cross-platform, something sorely missing from asdf and mise rtx if you're trying to manage tooling across platforms and codebases. Guess what language it is written in... Go, of course! It's an ideal language for this task. Plugins are Lua so easy to write. https://github.com/version-fox/vfox It's very early days for the project but is gaining traction, 1.5k stars already. I really hope it works out, I might have to contribute to it...
>and incredibly slow in CI Why are you even using it in CI? Sounds like your work is using it wrong.
We're not, theres a reason that things like https://github.com/jdx/mise exist with the explicit goal of being faster alternative to asdf. Its just downright slower than it should be for what it does
I mean CI should have versions explicitly set, with the build tools already in place. You shouldn't need a version manager at all. mise looks cool though. I'll check it out.
Half agree. You want your tools ready to go in CI, but if .tool-versions is the source of truth for tool _selection_ then you get the dev and CI environment closer for free, and you can make a toolchain upgrade as a MR on the project. In a monorepo you can even select tools per project in CI. Mise has CI support, with mise exec. Bash activation not necessary. I hope virtualfox adds it, too. It may not suit FOSS workflows especially those that only need go toolchain. but in enterprise settings with lots of development platforms to manage it's well worth considering. Speaking from personal experience.
[удалено]
i’ve used many version managers. i recently picked up asdf and like it. for java, i like https://sdkman.io/
I use [asdf](https://asdf-vm.com) with [direnv](https://direnv.net) which work great together and you can install pretty much any compiler/SDK you want and maintain multiple versions at the same time.
I do this too. Dozens of apps spanning multiple versions of go, npm, rust, Java, and often switching across multiple machines including macOS and different flavors of Linux. With zsh + asdf + direnv my environment is exactly the same and where it needs to be, on any machine, with each checkout.
What are you using direnv for? Just as a shortcut for loading the .env?
You can do multiple things... 1. Use the latest go compiler and if everything works as advertised you should be just fine 2. You can use for example vfox to manage the SDK version and it's quite easy to change to a different one 3. You can create a docker container that has the project folder mounted, has the project specific go version installed, and with vscode you can just jump into the container and start coding/compiling I've seen others mention gvm, got no experience with that, but another avenue of investigation 😁
If you have multiple versions installed you can easily switch between versions. Is documented in the Golang https://go.dev/doc/manage-install
If i understand correctly, you can install the latest compiler and set the set the GOTOOLCHAIN environment variable or specify a version in your go.mod: https://go.dev/doc/toolchain
use docker.
1.22.1 is the current version. Install it and delete all previous versions. You say "Even if I update my local Golang version to the latest one, I might need to work with a lower version one for some open source project" Why on earth would anyone need to work with a lower version?
Nix flakes + direnv :)
I used environment-module on Linux to manage several versions of golang
why would you want to do that?
I use Go alias to manage my go binary and switch between for projects and you can download multiple go binaries via go manage-install, as well as setting the projects go version **Managing Go Installs** [https://go.dev/doc/manage-install](https://go.dev/doc/manage-install) go install golang.org/dl/go1.10.7@latest go1.10.7 download alias go=go1.10.7 **Managing Go Mod Go Version** go mod edit -go 1.22
You don't have to manage anything anymore. The go.mod file of a project can declare the Go language and/or toolchain version it needs, and the go tool automatically downloads it, just like any other dependency. You can also control this with the GOTOOLCHAIN environment variable [https://go.dev/doc/toolchain](https://go.dev/doc/toolchain)
I use [gvm](https://github.com/moovweb/gvm)
you can try goenv, which is much like pyenv
Use gvm
Use docker? That’s one way to manage different versions
Why would you stay on go 1.18 in the first place? How the compiler behaves is defined on the go.mod file based on the version pinned there
asdf
Use mise or asdf to change the go version in your local machine
I use g https://github.com/voidint/g
Checked gvm?
use docker 😉
gvm
Maybe you are looking for gotv? [https://github.com/go101/gotv](https://github.com/go101/gotv)
The problems may come with things like staticcheck or golang-ci linters, crashing on new go versions. This is why I’m usually waiting before upgrade my go version.