We had a small benchmark tool written in Go. And people simply couldn't build it, they always came to me after banging their head trying.

This is basically what all of them did:

    $ cd <folder with all their projects and code>
    $ git clone <repo>
    $ cd <repo>
    $ go build

They just want to clone anywhere and run "go build".

You see this for Java projects where the whole source code is nested half a dozen folders deep (src/com/foo/bar/baz/myproject/...) so i don't think it's unfamiliar.

Some tools are fundamental. A tool to solve the problem of executing dependant tasks is one of them.

Solutions to these fundamental problems tend to be implemented early on. Some of those early solutions were poor, and have fallen out of use. Some of them were good, and have been refined in the intervening years, and hence are still with us.

A good tool to solve a fundamental problem is still useful, no matter how old it is.

I understand it'd be a pain to have Go setup, but once it is setup, it is great, When I write Go programs

I do

`$ cd /go/src/github.com/thewhitetulip/Tasks` `$ Tasks go build -o tasks` `$ Tasks ./tasks`

Go allows you to do a go get reponame and it'll do the git clone stuff for you.

that is nothing short of amazing as far as code management is concerned. I love it.

You can feel free to have any repo path you want :D

You obviously didn't vendor your dependencies in your project's vendor directory.

https://golang.org/cmd/go/#hdr-Vendor_Directories

I think the example there is hard to follow. Perhaps with more standard package names, such as golang.org/x/net or a popular github.com package, instead of the made up foo, baz, quux and so on it would be easier to understand exactly what advantages vendoring gives you.

You shouldn't have to!

A good dependency management system will produce reproducible builds via dependency versioning without any need to "vendor" anything.

It would be better if Go just downloaded all `go get` packages to some default fixed directory (%appdata%/go or whatever), and then the code the people manually download/write could live anywhere.

Otherwise you can write the other language code in the $GOPATH itself.

This is incompatible with path dependencies. When I was working on the YCM goto support for Go I had to rewrite all the imports in godef to be path imports because you can't go build packages with github deps outside of gopath. This rewriting had to be done in each file (and forced us to fork the package).

We wanted to use godef as a local folder because YCM wants to be able to pin to a version, usually via a submodule. `go get <github>` will be affected by silent updates.

Having everything in $GOPATH has the advantage that all your go code is in one place, but it's not much of an advantage because it's not flat -- you have to `cd github.com/<someusername>/<reponame>` whereas my regular `code` folder has a flat structure, with subfolders only for special cases (e.g. projects with multiple linked repos or whatever).

There are tons of disadvantages, which totally overshadow the minor advantage of automatically giving you a `code` folder -- something which is super easy to do without the "help" of GOPATH.

Fortunately a lot of these things get solved by vendoring, glide, and friends. Bare GOPATH is still terrible.

Aside from that, I do enjoy the language a fair amount.

The `src` folder you are talking about is a sub-directory inside a Gradle based project. This is entirely configurable within the Gradle build script, you can use multiple sub-directories for your source code or even the same directory as the build script if you wish. The reason Gradle uses a single `src` sub-directory by default is that it follows the Maven Standard Directory Layout.

It's like arguing that marriage equality violates your right to believe a marriage is between one man and one woman. One side is arguing that folks should be able to decide what's best for themselves, the other is saying it must be their way. One of these perspectives forces their preferences on the other. And it's not the GP.

That's basically the point.

It's like arguing that marriage equality violates your right to believe a marriage is between one man and one woman.

No, it's more like the Pythonic "There's one way to do it."

Nope, because it's "There should be one obvious way to do it." and you can still do the non-obvious way if you prefer.

It doesn't force anything upon you.

Something like `projects/go`

I have multiple GOPATH for personal reasons and use long running tmux sessions which exports the different GOPATH.

[0]: https://github.com/lloeki/dotfiles/blob/master/shell/go

I just set GOPATH=$HOME, and then all my source (Go & otherwise) is in ~/src, all my binaries (Go & otherwise) are in ~/bin, &c. It works really well for me. So some of the subdirectories of ~/src are a bit funkily-named: no big deal.

My only problem now is that I have so many projects checked out that it's hard to remember which ones I am contributing to vs which ones were checked out as a dependency. I think I can address that by setting GOPATH to ~/thirdparty:$GOPATH or something, but it hasn't bothered me enough yet.

We can already create multiple ones.