[always_good]

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

[cpuguy83]

You can write `import "./util"`

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.

[always_good]

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.

Two random links:

- https://stackoverflow.com/questions/38517593/relative-import... "No there is no relative import in Golang."

- https://github.com/golang/go/issues/20883 "Support relative imports in Go 2.0"

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

[cpuguy83]

Relative imports work, but keep in mind the import works based on package name. So "import ./foo", you must have a package called "foo" in "./foo"

----

Yes, it is easy to forget that we use vendoring to get around these issues (and for other reasons).

[cpuguy83]

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.

[weberc2]

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.

[viraptor]

Either "git grep" or configuring your ack/ag/... properly solves the search issue.

[weberc2]

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.

[GeertJohan]

> can't just write `import "./util"`.

Afaik thats actually possible. Or at least it was for a while. But there are good reasons why you shouldnt.

[rqs]

> But there are good reasons why you shouldn't.

Wonder why, care to explain?