Posted on Oct 21 The version 1.21 of the language implemented an essential new feature. According to the documentation:Starting in Go 1.21, the Go distribution consists of a go Command and a bundled Go toolchain, which is the standard library as well as the compiler, assembler, and other tools. The go command can use its bundled Go toolchain as well as other versions that it finds in the local PATH or downloads as needed.I did a proof of concept to validate how this new functionality works, which I will describe in this post.On my machine, I had the following version of go:I created three libs, each with a different version of go as a requirement. In the commands below, you can see the content of each go.mod of the libs:Starting with version 1.21, the go 1.20.0 line of the go.mod file, in this example of the l2 lib, indicates the minimum language version required we need to use to compile it.Next, I created a project to import the three libraries. The following diagram shows the dependencies:The main.go of the proj contains:The project's go.mod contains:I ran the project, and it worked without errors:Next, I simulated the process of updating one of the libs.To do this, I updated the l3 lib to a newer version of Go:I pushed it to the repository and created a new version (v0.0.1). According to the documentation:The Go toolchain refuses to load a module or workspace that declares a minimum required Go version greater than the toolchain’s own version.To validate this, in the project, I updated the version of l3:What's new is the following excerpt:What happened was that the go command updated the version of Go installed on my machine to 1.21.3:And the project's go.mod has also been updated to version 1.21.3.And the project continues to run without errors. My machine now has the minimum version necessary to import ALL libs and run without errors. In this case, it was updated to 1.21.3 because it was necessary to run l3 since the others are below the current version I had installed on my machine (1.21.0). Another fact I noticed is that there is now one version of Go for the project and another for the rest of the operating system:The go command identifies that the proj directory requires a specific language version. And all this management is done automatically.Let's now think about a slightly more complex example. Let's suppose that one of the libs, for example, l2, was updated to:The go command gets the list of available toolchains and finds that the most recent releases are Go 1.28.3, Go 1.27.9, and Go 1.29rc2. The go command will choose Go 1.27.9 in this situation.If l2 required Go 1.28 or later, the go command would choose Go 1.28.3 because Go 1.27.9 is too old. If l2 required Go 1.29 or later, Go 1.29rc2 would be chosen because the other options are too old.When executing the command go get github.com/eminetto/[email protected] (the newest version of the package), it will update the project's go.mod file, and a new line will be added with the chosen toolchain:You can find more details about the motivations behind this feature, the version naming, and advanced behavior settings in the language's official documentation.This feature is another example of the language team's care to maintain compatibility between past and future versions. With this functionality, it will be possible to guarantee the longevity of applications written in Go, which is very important for the future of the language in increasingly complex environments.Thanks to friends Matheus Mina, Tiago Temporin, and Eduardo Hitek for reviewing the text and suggesting improvements.Originally published at https://eltonminetto.dev on October 18, 2023Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well Confirm For further actions, you may consider blocking this person and/or reporting abuse arcade - Sep 3 Danny Hawkins - Aug 13 Arik - Aug 25 Momchil Atanasov - Aug 30 Once suspended, eminetto will not be able to comment or publish posts until their suspension is removed. Once unsuspended, eminetto will be able to comment and publish posts again. Once unpublished, all posts by eminetto will become hidden and only accessible to themselves. If eminetto is not suspended, they can still re-publish their posts from their dashboard. Note: Once unpublished, this post will become invisible to the public and only accessible to Elton Minetto. They can still re-publish the post if they are not suspended. Thanks for keeping DEV Community safe. Here is what you can do to flag eminetto: eminetto consistently posts content that violates DEV Community's code of conduct because it is harassing, offensive or spammy. Unflagging eminetto will restore default visibility to their posts. DEV Community — A constructive and inclusive social network for software developers. With you every step of your journey. Built on Forem — the open source software that powers DEV and other inclusive communities.Made with love and Ruby on Rails. DEV Community © 2016 - 2023. We're a place where coders share, stay up-to-date and grow their careers.