Hacker News Reader

Comment by FiloSottile | Hacker News Reader

Hey all, author here. Happy to take any feedback, in particular “I tried and it didn’t work out of the box” stories. I will NOT tell you to RTFM.

I recommend reading https://github.com/cloudflare/hellogopher#why for more insight.

There’s also a gif demo https://twitter.com/FiloSottile/status/822745605806112768

EDIT: uploaded the keynote I gave at Golab where I present the problem and introduce this project https://vimeo.com/200469720

View on HN

Thanks for making this, hope it catches on. As a non-gopher, whenever I came across a project where I needed to build a Go binary I'd get blocked by the GOPATH and since then I've just avoided such projects.

I did something similar for one of my projects (github.com/lunixbochs/usercorn) if you want another perspective. My primary goal was `make` would work out of the box in most environments (on OS X / Linux), even if you did not have Go installed at all.

This includes downloading the Go binaries for your platform, building three C libraries, fixing gopath, and automatically determining packages for `go get`.

https://github.com/lunixbochs/usercorn/blob/master/Makefile

Am I right to understand that it's "build from anywhere" as long as "anywhere" is not Windows? (Please don't tell me about MinGW/Cygwin if the whole idea is to "make life simpler".)

Anywhere in the FS of your OS From the readme: >They expect to just clone a repository anywhere, and be able to build it

Sadly, correct.

There is no way a standalone tool couldn't reproduce this behavior on Windows, and the eventual integrated solution definitely will, but it's just beyond the scope of hellogopher and outside my expertise.

I'm also a little confused. This is a fix for the standard go installer on platforms not setting a GOPATH, so that "go get" doesn't work without manually configuring GOPATH?

Or does it actually do anything else (except "break" windows builds - or rather introduce a system complementary to "got get" that isn't quite as cross platform as go itself)?

This is not about platforms (or about go get), this is about users who don't want to or know how to correctly use GOPATH.

It doesn't break anything, since you can still use go get, go build, or anything that worked before. It doesn't help Windows users, but it doesn't hurt them.

But as of 1.8 there is a default gopath negating that

A default gopath doesn't help a user who does "cd dev; git clone https://github.com/coolprojects/project; cd project; go build" (or make)

The default gopath does not help there. Sure, if a user knows how to use go's insane global-project-directory-bullshit then they don't need this, but since it's a go-specific bullshit, they might not.

Every sane language lets you have a directory where you want for each unrelated project. Only go dictates some crazy tree and defaults to creating it for you in $HOME

Right. But in order to build a go project, you need the go compiler. And the go compiler comes with "go get". So my question was more: if a user has installed go (properly) should not "go get" be the sane, easy, one way to install a project?

And isn't "fixing" "go get" better than adding a dependency on make?

(and I guess this project in a sense is a way to fix "go get", but it seems thrasher fragile; any one project might end up with a broken makefile by accident)..

A batch or PowerShell script potentially could (and it could even be named make.bat, so that instructions would stay the same). Windows does actually support symlinks, though the caveat is that it requires elevated privileges. See e.g.: https://en.wikipedia.org/wiki/NTFS_symbolic_link. I suppose some PowerShell magic could invoke the Admin password prompt, though there's also a question whether it'd be good to condition users to require elevated privileges for some random just downloaded script.

Reply on news.ycombinator.com