Eh, it wasn’t the best, but it was still better than any other language’s equivalent except for Rust’s. In any case, modules have worked wonderfully for me so far.
> but it was still better than any other language’s equivalent except for Rust’s
I'd say almost any language with project-specific deps folder (e.g. Node, Elm) are better than GOPATH and its module system.
For example, can't just write `import "./util"`. It needs to be fully qualified, every import depending on full project fs hierarchy including even the project user/name on github. This is hilarious when you just want to fork a project from github and get it running.
Also, it's really not that bad considering that go works (`go get` grabs git repo) with git repos. So you can go into your GOPATH (or vendor dir) and checkout your fork in place of the origin.
In the end, a little pain to get started to get used to it, then it's second nature.... but I suppose if you primarily work in other languages it is likely tiresome.
All three replies to me suggest that you can do relative imports in Go.
Can you link me to documentation that demonstrates them?
I don't understand. Either relative imports are not supported or they only work in some context that nobody uses. BTW I'm not a Go beginner, and my issues with Go aren't just an issue with "getting started" as you suggested.
I just tried them in an existing Go project and I get the usual "can't load package" error.
> So you can go into your GOPATH (or vendor dir) and checkout your fork in place of the origin
Imagine the real-world case where you're working on more than one project at a time. Project X and Project Y both depend on a Util project on GOPATH, but they require different versions of Util.
Each time you switch projects, you cd into GOPATH and check out the right version of Util?
I'm sure this stuff works for a megarepo like the one Google has. But for the rest of us, this stuff was solved by package managers. A lesson Go ended up having to learn in the end.
By the way, wasn't trying to suggest that you are new to go, just that I understand there is some tribal knowledge involved that make it difficult for new comers and people who don't spend much time working with the language.
I vaguely recall wanting relative imports back when I first started dabbling with Go. Then I moved on and really have completely forgotten it was an issue.
If you want to fork a project, I'm pretty sure there's a program (gorename maybe?) that rewrites these import paths for you, but I've always just used `sed`.
I haven't used Elm, but Node's `node_modules` folder has always been a hassle. Grepping for anything is a pain, and regularly the directory seemed to just get borked so you'd have to `rm -rf $(find . -name node_modules) && npm install`. I don't want to overstate this problem; Node wasn't what I had in mind when I was thinking of difficult project conventions.
Yeah, I'm sure this is fine if you're a full time Node developer. I just pop in; also I use a lot of tools besides grep and ag (for example, vim and VSCode) and having to configure every one of them is tedious. Also, IIRC if you want to make a Docker dev image with your dependencies installed (into which you mount your source code) it gets challenging to interweave your dependencies with your source files (this probably has a nicer solution; I just recall this being a pain point when we set up our Docker infrastructure). Again, I don't want to overstate the problem, I just happen to prefer dependencies out of the source tree.
> Eh, it wasn’t the best, but it was still better than any other language’s equivalent except for Rust’s.
I disagree. Gopath was the most brain-dead idea being implemented in a current programming language. It handled the problem in a far worse manner than any other programming language in current use. This problem was then made far worse by the way the language developers insisted in forcing it upon go users in spite of all the repeated compains.
Really there are relatively few complaints from Go users. Most people just read the paragraph explaining how GOPATH works and get to work. Most of the complaints come from outside of the community--people who are frustrated that Go doesn't copy their favorite language's project files, build tools, project structure, etc. Anyway, since you don't have any actual criticism of GOPATH (just that it's "braindead" and "far worse"), I can't really do much except disagree, because GOPATH was already quite a lot nicer than the equivalent in most other languages, and modules makes it even better!
I'd say almost any language with project-specific deps folder (e.g. Node, Elm) are better than GOPATH and its module system.
For example, can't just write `import "./util"`. It needs to be fully qualified, every import depending on full project fs hierarchy including even the project user/name on github. This is hilarious when you just want to fork a project from github and get it running.