Re:Go 1.17 is deprecating the traditional use of 'go get'
by hnlmorg on Friday June 25, 2021 @12:16PM
(#27632702)
> But unlike many other ecosystems, in Go it's quite common to expect the developer to have moved to a somewhat recent version.
You'll find that true for any language and framework created within the last 15 years (and some that are older than that too). Rust, Nim, node.js, TypeScript, .NET, etc. And it's to be expected too, for the following reasons:
It's really more down to development pipelines. If your pipeline requires additionally installing the language and/or framework (eg Go doesn't ship by default on most operating systems, it's an optional install) then you're going to expect a recent version to be installed since you're having to install it anyway and since you're not going to break a mass of existing OS boilerplate that might depend on an earlier version being installed (as is often the problem with Perl, Python, shells and others).
Also if a language is newer, then there is often a higher pace of in demand features with each new release. If Go were 30 years old you can bet most of the features people might want would either already be implemented or developers that might want those features wouldn't be giving Go a second glance and instead working with other languages instead.
The longer you work in IT the more you see this cycle repeat over and over. It's almost comical how cyclic the industry is.
You'll find that true for any language and framework created within the last 15 years (and some that are older than that too). Rust, Nim, node.js, TypeScript, .NET, etc. And it's to be expected too, for the following reasons:
It's really more down to development pipelines. If your pipeline requires additionally installing the language and/or framework (eg Go doesn't ship by default on most operating systems, it's an optional install) then you're going to expect a recent version to be installed since you're having to install it anyway and since you're not going to break a mass of existing OS boilerplate that might depend on an earlier version being installed (as is often the problem with Perl, Python, shells and others).
Also if a language is newer, then there is often a higher pace of in demand features with each new release. If Go were 30 years old you can bet most of the features people might want would either already be implemented or developers that might want those features wouldn't be giving Go a second glance and instead working with other languages instead.
The longer you work in IT the more you see this cycle repeat over and over. It's almost comical how cyclic the industry is.