`go get` isn't a command you should be using to just be a handy way to clone a git repo to your PC. Yes, that was literally what it does today and that was effectively the workflow before modules.

But GOPATH is deprecated so you shouldn't be relying on that anymore anyway.

The expectation is that the user just clones your Git repo to _anywhere_ on their PC and runs `go test` there. If they want to consume this local development version in their application then they use a simple `replace` directive in their go.mod to point their dependency at their local version.

If they're still using GOPATH then that's something they can probably manage themselves honestly. That's just a simple folder move. It's been like, what, nearly 2 years since GOPATH was deprecated?

This is everything wrong with modern languages/toolsets. Constantly changing everything, pulling the rug out from people who just want to get work done and wasting everyone's time who googles how to do something and has to go through 3 outdated answers to figure out the current way to do something. Deprecation and breaking changes should be an absolute last resort in the face of overwhelming necessity, not something done on a whimsy to please the aesthetic preferences of some new project manager who needs to feel important.

I don't know that I disagree per se, but GOPATH and modules mean that the tooling has to handle two different cases which are often surprisingly ambiguous and it creates real headaches for the user. There's a lot to be said for having a single path forward even if it means existing users will have to experience some mild pain (i.e., learning a new workflow, rewriting some build scripts, etc) one time. Ideally language developers would have perfect foresight from the outset such that no changes are ever needed to the language, but sadly such language developers are hard to come by.

> GOPATH and modules mean that the tooling has to handle two different cases...

No, the main thing, that GOPATH meant, is that Google (and everyone else) had to make their Go libraries open-source — since entire logic of GOPATH revolves around building stuff, downloaded from Github.

Once Google management decided to be serious about pushing Go to masses, they hurriedly rushed to erase GOPATH from history (just like they erased "Don't be evil" slogan from Internet after getting serious about doing business).

You don't know shit. I “hate” Go and Google with a mild passion (I mean this lightly, rhetorically) and still know enough to explain to you that modules have nothing to do with publishing binary blobs (which like isn’t even a thing in the go ecosystem) or private repos. Modules add a layer of indirection and solve so many actual problems with the GOPATH like “how do you have a dev copy with local changes and a main copy of a library on the same machine?”, “how do you manage/scope different versions of the same dependency between/to different projects?”, etc. GOPATH was so abysmally short sighted only Google could have created it.

Just checked, and looks like you are right — modules don't offer more facilities to distribute proprietary code than GOPATH already did.

I stand corrected.

...what?

GOPATH has nothing to do with GitHub. It is one of the places that has special case handling, but is absolutely not the purpose of GOPATH. Case in point: the VM I have to build some legacy stuff using GOPATH does not have a _single_ dependency from GitHub. Not one. Nor does it contain any open source code, besides the standard library.

Indeed, — GOPATH does not imply using Github, and Github does not imply open-source (even if it is one of the most widely used ways to host open-source).

The logic of GOPATH and "go get" just so happen to revolve around building packages, fetched from source code repository. This logic used to be a stop-gap, written during early stages of Golang development, and makes it awkward (at best) to distribute proprietary Go libraries. I assume, that Google is introducing module system (and aggressively deprecating GOPATH) to work around this issue (among others).

Yeah, the parent seems to think that GOPATH has something to do with pulling from GitHub and that modules implies some central repository which isn't the case at all. If you use modules, you're also pulling from GitHub directly in most cases, although nowadays there is a public caching proxy in the middle IIRC. And in both cases you could/can use private repositories.

Go is really bad at this. They claim to care strongly about backwards compatibility, but have repeatedly changed and broken how tooling works.

It is Go, the language, that provides a backwards compatibility guarantee.

Another tenant of Go, the language, is specification before implementation. There specifically so that many implementations of the language are created and do not become dependant on quirks of a single set of tools and enabling users to choose which tooling they prefer.

Point being, there is a very clear line drawn between Go the language and the Go distribution. Guarantees provided by one are not necessarily applicable to another. Nor do they apply to gcc-go or tinygo.

> This is everything wrong with modern languages/toolsets

Go can hardly be called a modern language. The usual argument we hear on HN is that it has an absolutely stellar backwards compatibility story. Are we losing that too?

> Go can hardly be called a modern language.

I'm not sure what this means exactly, but it's a significant advance in simplicity and productivity in my experience.

> The usual argument we hear on HN is that it has an absolutely stellar backwards compatibility story.

This refers to the compatibility of the language, not necessarily the tooling. Even still, this is a single change, there's no need to panic about losing backwards compatibility just yet.

No language without FP or OOP can be called modern. Go is an ancient version of C with less features.

I knew it was optional. I didn’t know GOPATH was deprecated !

To be clear, the whole GOPATH development workflow is deprecated. But the GOPATH environment variable isn't, since it's still used for configuring the location of other things like the module cache.

Is there a convenient write up/tutorial of the latest suggested workflow that is "go get"-less and "GOPATH"-less?

i use golang on and off and i always have to remind myself the difference between GOROOT, GOPATH, and GOSRC. the seeds of confusion was sowed from the get go.

> the seeds of confusion was sowed from the get go.

I see what you did there...

I wrote this little shim to replace the old `go get` behavior. https://github.com/icholy/git-get

> I wasn't able to just update the docs and recommend `go install` because it doesn't work with old Go versions

I don't think your documentation has to be backwards compatible in this case. If you must split it into two sets of instructions based on Go versions, you can. But unlike many other ecosystems, in Go it's quite common to expect the developer to have moved to a somewhat recent version.

I will say I had projects using dep and/or relying on a GOPATH-style directory layout with my build scripts, but that ship has sailed with just about any new libraries one might depend on. I don't think anyone would blame you for your library moving on too.

> in Go it's quite common to expect the developer to have moved to a somewhat recent version.

People and organizations decide when they will move versions based on their own project lifecycles and requirements, usually (outside of the Go community?) not just because the language vendor says there is a new version and it's time. This is something that was hard for me to cope with as a Rubyist, who was always doing everything to be on the latest version.

I'm new to the Go community, but I can already see the effects of this in Kubernetes, and I don't necessarily think it's good the way things are. Kubernetes 1.16 was released in 9/19 and already EOL and out of support in 8/20, less than a year later. (It took some time for many cloud vendors like AWS to catch up, EKS only landed K8s 1.16 in April 2020. That's four months of usable life before it was officially out of date.)

Integrated things that worked in August of 2019, probably need work again in 2021. As a software developer I understand this and "yeah, we need to always be upgrading" is part of my mantra, and it has been clear to me since I was a teenager that I will spend time struggling with problems that I would not even know about, unless I run Debian "unstable" or an equivalent rolling release distro, where patches can be accepted from upstream at any time of year, whether or not they contain new features.

But I could never get my bosses to see it this way, working in a company that was not firmly embanked inside of the "Cloud-Native" sphere of the world. The "normies" I've always worked with didn't want to see new features popping in at any time, they wanted their own predictable environment that works the same as it did yesterday, to stay that way all year long.

(Edit: and for what it's worth, Ruby does a pretty good job of being stable all the time I've used it professionally for the last 8-10 years, and in spite of having chosen it themselves, they still hate it. Anyway, that's what they say they want...)

"I'm new to the Go community, but I can already see the effects of this in Kubernetes,"

Well, then, good news, this is mostly an effect of Kubernetes being its own ecosystem. It's implemented in Go but it is not generally considered a good example of a Go project. First of all, there's a great blog post somewhere about not looking to the largest projects in any language in general, because they tend to become their own ecosystems, but I don't know where it is. It's right, though. Secondly, Kubernetes is an extra-specially-bad example of a Go project because it's actually a Java project that was ported into Go, and even today the architecture makes that very clear that's how it evolved.

The Go ecosystem in general is actually pretty good about backwards compatibility. If you're starting out new, you shouldn't even necessarily notice this "go get" change because for you the new way will just be how it works, and the new way is easier to understand for a new person than the older, more confused way is. Plus, you have to opt-in by upgrading your Go compiler, and that's really quite optional; if you choose to stick to one for a while, you don't miss out on many libraries, because the language hasn't changed much. It isn't until generics drop that you'll start seeing libraries that you must upgrade for, and if you ignore the libraries that are literally "we're deliberately using generics to do things we can only do with generics" I expect it to be even another year or two minimum before you start seeing other more generally-useful libraries start to require them. I certainly don't intend to go back to all my libraries and retrofit them with generics just because. I don't think there's a lot of pressure to keep up with the latest compiler all the time.

HN has a lot of people waiting with bated breath for Go stories to drop who like to come in and complain vigorously about whatever the Go team has done, despite not using the language themselves. I don't mean to discount people with real experiences, but HN's sound and fury are not always proportional to the real problem. (Just because someone don't like Go's type system and the fact that it lacked generics for so long doesn't mean that piling on and moaning about some not-all-that-significant change in how the tooling one wouldn't be caught dead using and don't know much about is a useful thing to do.)

"Don't even get me started on Generics" no I'm just kidding, but I've read this debate plenty of times before :D

Thanks for the perspective. That makes sense, I wrote how they don't really like Ruby even though it is very stable like they said they wanted, and rarely makes breaking changes (and takes great care to ensure they are well documented and easy to follow when they happen) ...

Then I thought about Rails, and decided not to say anything about Rails, (because it might undermine my whole argument, as that's where arguing from this position breaks down a bit.) Rails isn't really that bad with breaking changes, but it is where most of the breaking changes probably come from, and therefore probably worst thing to use as an example... like you say with Kubernetes in Go!

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

I think people will be happy if the instructions work with the latest Go version (as opposed to instructions that are outdated either because the project is not maintained anymore or it is still maintained but nobody bothered to update the docs).

So it will be exactly one major version that supports both the new and old ways, as I read it? Sounds tight for such a significant change. I'd give it at least 2.I don't see the rush.

The current version already supports both ways.

My bad!

I used to use `go get` for grabbing even non-Go repos but had to stop because of similar problems. I finally wrote a small tool to replace it I call `grab` https://github.com/jmhodges/grab to take over my "fetch the code and organize it into a tidy directory system" need

It actually uses the nice VCS library guts that `go get` does!