In my opinion its more like: Go comes with a package-management/install system onboard, and for every 'go install', there's a full copy of working sources which someone, some day, might consider reading and contributing to ..

So I think, at least as a go newbie, that its quite handy that pretty much every tool I might be interested in - because it was written in Go - comes with full sources onboard as a basic, starting-gate, expectation. At least, I am quite happy to be learning Go this way ..

Because he's sharing the source code rather than a compiled binary. It's no different to having make + gcc listed as a dependency for C++ code.

Strictly there is a little hindrance for the non-gopher user because this won't work until they set up a Go workspace, i.e. decided where they want GOPATH to be, set that, and added $GOPATH/bin to PATH to have the executable be runnable.

    $ env -i $(which go) get github.com/schachmat/wego
    package github.com/schachmat/wego: cannot download, $GOPATH not set. For more details see: go help gopath

Indeed, but that's a separate point. The question was why Go was listed as a dependency and my answer was because it's a source code repository.

Also, you left off GOROOT from your Go environment :)

> The question was why Go was listed as a dependency

You may have read it that way but the question was explicitly referring to "working Go environment"

Only because that was the terminology used on the Github readme. He was quoting it verbatim rather than asking what environmental variables needed setting. The reason I think this is because he also went on to say "I thought one of golang's selling points was the fact that it created a simple binary." which relates directly to discussions people make about JIT compiled (eg Python, Javascript, etc) vs AOT compiled (eg C++ and Go).

It's also worth noting that you're only specifically discussing environmental variables, where as a development environment is more than just that. Aside having your build tools in PATH (and lets not forget that gcc and make need this just as much as go does), you need supporting shells for the ./config(ure) scripts, any source libraries for C++ includes, and so forth. So you could equally use the same "working [language] environment" terminology to describe C++ - or in fact any other programming language too.

Which is why I think he was asking why he needed Go installed to begin with.

Alright, well hopefully somebody gleans something from our little thread either way.

Absolutely. I'm happy to `apt-get install` something, but the conceptual overhead of "let me configure a $language development environment" is high enough that I'm not going to bother just to install this awesome looking tool.

I'd love it if this had been packaged in a way similar to Python or Node tools, where installation is as simple as 'install Python and pip; pip install my-program', and more-experienced users (or those who want source) can clone the git repo.

So request a binary then. You're basically moaning that an open source project is shipping source code.

And FYI, Go is in quite a few distro repos so you might be able to just:

  apt-get install go-lang
  mkdir -p ~/go/src ~go/bin
  export GOPATH=~/go
  go get github.com/schachmat/wego
  go install github.com/schachmat/wego

However considering this is an open source CLI tool, I don't think it's at all unreasonable to expect he user to do a bit more manual work to compile and run this tool from the command line.

In fact, quite frankly, I find it rather disgusting that someone should share their work and source code like this and have others moan simply because they're too bloody lazy to compile it themselves. I mean seriously guys, this is Hacker News, not PC World Magazine.

It actually does work this way. 'Install Go; go get github.com/me/my-program'. Done.