Hacker News Reader

The document was overhauled earlier this year to make it easier to understand. Apparently, it's not easy enough.

The substantive criticism I saw here was the one about versioning packages, which I think has led to some of the awkward choices. If you're collaborating and using packages from github etc (as go get encourages you to do), it isn't possible to document which version you're using so that go get will fetch one version till you decide to upgrade everyone. You have to freeze the dependencies somehow by hand (which is mostly what has led the author beyond the pale).

If this is seen as not a problem Go wants to solve, perhaps it should be documented up front, as it's something which comes up again and again when people start using Go coming from languages with an established package ecosystem. Almost every other language I can think of versions libraries explicitly, so Go is quite unusual in this regard. For example under 'Remote packages' in that page you link, there is no mention of versions at all.

    > Although the author touches on some real issues with 
    > writing applications in Go, I do not recommend this 
    > article. The author does not follow the recommended 
    > practice for writing Go applications and the author has 
    > misconceptions about the Go tools.

Strongly agree. The author's workflow is full of antipatterns.

Perhaps the people who click with Go will just be different in their natures than people who click with other systems and frameworks. Programmers are not a uniform population, and tools which map well with subsets have real value.

For Slartibartfast I decided to give this project its own Workspace, with its own $GOPATH, and put the entire Workspace into git. This is not the recommended practice. ... That's enough nitpicking. The take away that I get from reading this article is that "How to Write Go Code" (http://golang.org/doc/code.html) needs improvement. The document was overhauled earlier this year to make it easier to understand. Apparently, it's not easy enough.

When I started with Go, I was doing something similar: each project got it's own directory and I had to update the $GOPATH environment variable for each. It was probably a month or so before I had the "Ah-hah" moment that I didn't need to do that. Looking over the (nicely revised) "How to Write Go Code", this clarification is still missing from the The GOPATH environment variable section.

The Go Tool page (http://golang.org/cmd/go/) is required reading if you're going to get anywhere with Go.

It would also be really nice to have a resource that demonstrated some Go design patterns (at least a factory...).

Articles like this -- even if they have errors or arguable non-best-practices -- should be recommended because they drive conversation. Thus far one of the most unfortunate things I've noticed about the Go community (and this is seen even in discussions about Go on here) is a silence that results from a fear of doing things wrong. That improves no one.

The 'go list' command will tell you the dependencies for an application.

Does it? I thought it simply showed every package in the application, not differentiating what is yours and what is not. If I am correct, in no way does it solve the problem that they were trying to address.

This is not the recommended practice.

They specifically note that it isn't the recommended practice, but that it was a compromise to make a more easily reproducible structure. It is absolutely odd -- from a traditional developer perspective -- how the structure of a go application works when there are many dependencies, and I'm not sure what is the recommended practice for actually source controlling that (though we know how individual packages should be managed).

Go files matching the build tags are compiled into the resulting binary

Can you describe what you means? Such as

go build github.com/mypackage?

I've built several solutions with Go now and remain sure that much of what I'm doing is wrong, despite trying to find the relevant information.

> > The 'go list' command will tell you the dependencies for an application.

> Does it? I thought it simply showed every package in the application, not differentiating what is yours and what is not.

How is that not telling you the dependencies for an application? And differentiating yours from others ought to be trivial if you use the recommended directory structure with the path under /src corresponding to repository locations.

Many real applications consist of tens to hundreds of packages, tens to hundreds which might be in development in the application, and tens to hundreds which might be dependencies.

I fail to see how following the recommended directory structure (which is assumed) helps that, beyond that you can then correlate with a separate list of "things that are mine".

In a Visual Studio project, just to bring up a comparative example, I have my solution and projects. And then, elsewhere, I have nuget dependencies. There is absolutely no question which is which (nor is there any confusion on how to source control the whole, including that the dependencies include nothing more than pointers to their location/version). In my go project there are hundreds of seeming equals.

> I fail to see how following the recommended directory structure (which is assumed) helps that, beyond that you can then correlate with a separate list of "things that are mine".

If you are following the recommended directory structure, you don't need to "correlate" to "a list" of things that are yours, as all of your things will be under a path that corresponds to your remote repository, while external dependencies will be under paths that correspond to other remote repositories.

> In a Visual Studio project, just to bring up a comparative example, I have my solution and projects. And then, elsewhere, I have nuget dependencies.

In Go, you have the solutions and packages under (e.g.)

  /src/github.com/corresation/

And then, elswhere, you have dependencies that aren't yours.

The issues with package versioning and dependency management are well known and frequently discussed in the Go community. This article does not cover new ground in that discussion.

To list the dependencies for the application github.com/user/myapp, run the command:

    go list -f '{{.Deps}}' github.com/user/myapp

The command

   go build github.com/mypackage

builds github.com/mypackage and its dependencies. If github.com/mypackage is a command (a package with name 'main'), then the resulting binary is written to the current working directory. If github.com/mypackage is not a command, then you probably want

    go install github.com/mypackage

This command builds and installs the package.

> The issues with package versioning and dependency management are well known and frequently discussed in the Go community.

Is there a good place to see the current status of that discussion, or is it just spread across the mailing list?

Nathan Youngman's document is a good summary. https://docs.google.com/document/d/1_IJTRD6dDQvyCfyim4KJexq8...

There are many threads on the mail list. There was probably one this week :).

> Articles like this -- even if they have errors or arguable non-best-practices -- should be recommended because they drive conversation.

I disagree. You could use the same argument to admit any old troll. As someone who's often critical of Go, I found the quality of TFA to be too low to be worthwhile. It gets a lot of things wrong and in my opinion breezes past many of the real problems.

More importantly, with new languages people are very quick to sling whatever FUD they can regurgitate against languages they've decided they don't want eating up the mindshare they'd rather some other language had.