4 ms·

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 pra

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. a developer can not expect anyone to individually go get 20-plus different packages Because the 'go get' command fetches dependencies recursively, there's no need to 'go get' packages individually. the developer is forced to remember which packages the application uses, and which are other projects The 'go list' command will tell you the dependencies for an application: go list -f '{{.Deps}}' path/to/application 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. each package is expected to be in its own source repository A repository can contain more than one package. There's no requirement that a package exist in a repository. go get probably works great for the needs inside of Google Google does not use 'go get' internally. anything placed in the src/[package] directory gets compiled into the resulting binary Go files matching the build tags are compiled into the resulting binary. Everything else is ignored, including Go files that don't match the build tags. 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 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.

redbad 13y ago
> 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.
- jjindev 13y ago
  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.
grey-area 13y ago
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.
corresation 13y ago
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.
- dragonwriter 13y ago
  > > 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.
  - corresation 13y ago
    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.
Arnor 13y ago
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 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/ 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...).

redbad 13y ago

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

jjindev 13y ago
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.

grey-area 13y ago

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.

corresation 13y ago

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.

dragonwriter 13y ago
> > 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.
- corresation 13y ago
  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.

Arnor 13y ago

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