Hacker News Reader

Comment by bschwindHN | Hacker News Reader

It's opinionated, and not the good kind. Some people like having simply a `projects` directory with all coding projects inside. For almost any language, I can clone into this directory and run the associated build scripts. But Go has to be special and use a special directory or else it throws a hissy fit.

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

View on HN

Its almost exactly the same as gradle java projects. Each module there has a 'src' directory where all code and whatnot lives. And nothing's stopping you from having a one-liner bash script that sets up the base as the GOPATH and then running `go build`/

I don't think it is at all same. You can clone a Gradle-based project anywhere (e.g. /projects), cd into that directory and run `gradle build` and it will work. There is no `GRADLE_PATH` or similar environment variable determining where all your Gradle-based projects must live.

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.

You can always symlink a project located in your GOPATH to your `projects` directory.

It's brittle and confusing nonetheless. Having to set up Go on all the machines I use is a pain I could do without.

Then don't? This is just being opinionated in the other direction and declaring yours the right one.

This is inane. The approach GP is talking about lets any developer manage the space above their project however they care to. The `GOPATH` approach forces this one structure upon you.

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.

The `GOPATH` approach forces this one structure upon you.

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

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

How many machines do you develop in? go getting and ln -s in your code folder isn't exactly an ardous, confusing task.

You can make a sub directory of your `projects` your GOPATH.

Something like `projects/go`

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

That's what I currently do. It's really just a minor annoyance, but it is an extra layer of friction for any newcomers to the language (and a pretty bad first impression)

I use a `.gopath` file and some small shell support[0] to just `cd` into a go workspace among many. That said, the "clone and be done" approach is something I miss sometimes.

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

> But Go has to be special and use a special directory or else it throws a hissy fit.

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.

Reply on news.ycombinator.com