5 ms·

Application Development in Go

87 points by jameskilton 13y ago

jjindev 13y ago
It seems the go team chose a method that would produce zero name collisions under parallel development. That's the highest goal, but of course the burden of it is that paths below /src must be kinda long to support it. A "rare collision" solution could have been more concise without being as robust.
- freyr 13y ago
  A common theme in Go is "Do important things the correct way," even if that equates to slightly more work for the developer. People will inevitably argue about (a) what's really important, and (b) what's really the correct way. But they didn't create Go. It's clear where Go's creator stand on the issues.
  - jjindev 13y ago
    I had a funny experience. Before I ever worked with Go a developer I'd worked with (and argued small details and big philosophies), told me "why don't you use Go? It seems your kind of language." From my later glances it seems like he was right. So I might be in the fortunate subset for which the philosophy matches, more or less.
- dragonwriter 13y ago
  > It seems the go team chose a method that would produce zero name collisions under parallel development. Well, that and also one which produces a mapping between local paths and repository locations so that you don't need much (or any, in most cases) package metadata or a central directory service, creating a decentralized/distributed package management system. > That's the highest goal, but of course the burden of it is that paths below /src must be kinda long to support it. I suppose, but I'm not sure long paths is really all that big of a burden.
BarkMore 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. 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.
evmar 13y ago
An easier approach to the submodule problem is to use "git subtree" to copy in any dependencies of the project into your tree. Then (1) your project always builds against exactly the version of the dependency you tested against, and (2) if someone else deletes their repo it doesn't affect your project (unlike git submodules).
- jameskilton 13y ago
  I was unaware of `git subtree`, I'll take a look at that option, thanks.
- eknkc 13y ago
  What if my dependency depends on something else and that something else breaks things when it's updated? Is there a decent way to lock all dependencies recursively?
grey-area 13y ago
First, a developer can not expect anyone to individually go get 20-plus different packages (Slartibartfast has more than 10 and growing), not to mention whatever 3rd party dependencies the application uses, to work on a single application. go get fetches dependencies, so this is not an issue with go get, anything imported will be fetched. There is no place to put such resources in the normal Go Workspace, as anything placed in the src/[package] directory gets compiled into the resulting binary and is not accessible or editable from outside. It's quite possible to put resources into a go pkg folder without causing problems, and those are go gettable along with the code. I don't see the issue here. Running go get for a package clones the repository at its current HEAD/master/trunk, with no way of specifying a version or commit you might want. Go get doesn't (yet) get versions of packages, just fetches the master. This is something that's been discussed to death on the mailing list, there are plenty of threads: https://groups.google.com/forum/#!forum/golang-nuts https://groups.google.com/forum/#!forum/golang-nuts Some solutions to that are: Go get everything once, and then stop using go get (the solution in the article, though he brings workspaces into it too, which is unnecessary) - this is problematic as he points out. Put all your dependencies into subpackages, frozen at a particular version, I like this solution for now. Put all your dependencies into your own repo, again frozen at a particular version, and only go get or checkout from there Use something like gonuts.io to add versioning information (relies on the pkg authors to do this though) Add versioning to go get to check out versions to a specific path. It would actually be pretty easy to add version dependencies to Go by adapting the go get source. go get already versions for version of the language by looking for a certain tag, but not versions of the package. You could just check out to a path like src/github.com/jasonroelofs/slartibartfast/1.0/ and use that path for imports. Someone should just go ahead and do it, to see how it works out - if it's popular, people will use it, and eventually it might make its way into the default distribution. The folks at Google just don't seem to see it as a problem so presumably their setup/usage doesn't hit this problem.
- jjindev 13y ago
  My fantasy vision, predating go, was publisher/project/version with /src and /bin below all that (separate bins and srcs). I am open to re-balancing that tree ;-), but somewhat surprised that version wasn't in from the beginning. Perhaps there were more worms in that can that I expected. (version should be constrained to x.y.z numeric form)
tyleregeto 13y ago
We use per-project work spaces too and it has simplified a lot of things for us. The biggest reason for this is that our projects aren't just Go based, their are other languages in there, many different file types. Building the project doesn't mean running "go build", that's just one component of a much larger code base. A complete build for a web application means: * compile the Go app * compiling the Sass files down to CSS * combining and minifying Javascript files * minifying HTML files * optimizing/compressing image assets * etc. These things need to happen together, and than are organized into the deployable file structure. Ofcourse this is all automated with scripts, but a single global Go workspace doesn't cut it. It assumes that the Go app is king, while in reality its just another component.
- kin3tic 13y ago
  How does it not? src/main.go src/_web/{css,js}/whatever.{js,css} It's not even remotely difficult and your build process is now: "go build && run_whatever_to_minify _web/css _web/js _web/img". How on earth does having assets in the Go source tree cause any complication whatsoever?
riobard 13y ago
I have similar problems building Go apps for internal use. My solution so far is to use per-project $GOPATH and `git subtree` to manage the whole $GOPATH as a single repository. The primary benefit of doing so is build repeatability: any dev can `git clone` the repo and build the app successfully after setting the $GOPATH to the repo directory. Changes in external dependencies have no affect on us until we manually incorporate them into our repo via `git subtree`. There is no need to `go get` and we avoid its associated problems (e.g. versioning, availability of remote repos, etc).
kin3tic 13y ago
Almost nothing in this article is correct. * No you don't have to manually go get dependencies of things you're already 'go get'ting * Why the fuck would you put the workspace itself in version control. That makes absolutely no sense at all. * Non Code Resources hang out in src/ just fine. You think that you BMP gets rolled into an executable file? You can, if you CHOOSE to, but no, by default, you distrib your assets next to your binary and reference them with a relative path. (Aka, the same way you do in every language/environment ever...)

87 points by jameskilton 13y ago

It seems the go team chose a method that would produce zero name collisions under parallel development. That's the highest goal, but of course the burden of it is that paths below /src must be kinda long to support it. A "rare collision" solution could have been more concise without being as robust.

freyr 13y ago
A common theme in Go is "Do important things the correct way," even if that equates to slightly more work for the developer. People will inevitably argue about (a) what's really important, and (b) what's really the correct way. But they didn't create Go. It's clear where Go's creator stand on the issues.
- jjindev 13y ago
  I had a funny experience. Before I ever worked with Go a developer I'd worked with (and argued small details and big philosophies), told me "why don't you use Go? It seems your kind of language." From my later glances it seems like he was right. So I might be in the fortunate subset for which the philosophy matches, more or less.
dragonwriter 13y ago
> It seems the go team chose a method that would produce zero name collisions under parallel development. Well, that and also one which produces a mapping between local paths and repository locations so that you don't need much (or any, in most cases) package metadata or a central directory service, creating a decentralized/distributed package management system. > That's the highest goal, but of course the burden of it is that paths below /src must be kinda long to support it. I suppose, but I'm not sure long paths is really all that big of a burden.

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

evmar 13y ago

An easier approach to the submodule problem is to use "git subtree" to copy in any dependencies of the project into your tree. Then (1) your project always builds against exactly the version of the dependency you tested against, and (2) if someone else deletes their repo it doesn't affect your project (unlike git submodules).

jameskilton 13y ago
I was unaware of `git subtree`, I'll take a look at that option, thanks.
eknkc 13y ago
What if my dependency depends on something else and that something else breaks things when it's updated? Is there a decent way to lock all dependencies recursively?

grey-area 13y ago

First, a developer can not expect anyone to individually go get 20-plus different packages (Slartibartfast has more than 10 and growing), not to mention whatever 3rd party dependencies the application uses, to work on a single application. go get fetches dependencies, so this is not an issue with go get, anything imported will be fetched. There is no place to put such resources in the normal Go Workspace, as anything placed in the src/[package] directory gets compiled into the resulting binary and is not accessible or editable from outside. It's quite possible to put resources into a go pkg folder without causing problems, and those are go gettable along with the code. I don't see the issue here. Running go get for a package clones the repository at its current HEAD/master/trunk, with no way of specifying a version or commit you might want. Go get doesn't (yet) get versions of packages, just fetches the master. This is something that's been discussed to death on the mailing list, there are plenty of threads: https://groups.google.com/forum/#!forum/golang-nuts https://groups.google.com/forum/#!forum/golang-nuts Some solutions to that are: Go get everything once, and then stop using go get (the solution in the article, though he brings workspaces into it too, which is unnecessary) - this is problematic as he points out. Put all your dependencies into subpackages, frozen at a particular version, I like this solution for now. Put all your dependencies into your own repo, again frozen at a particular version, and only go get or checkout from there Use something like gonuts.io to add versioning information (relies on the pkg authors to do this though) Add versioning to go get to check out versions to a specific path. It would actually be pretty easy to add version dependencies to Go by adapting the go get source. go get already versions for version of the language by looking for a certain tag, but not versions of the package. You could just check out to a path like src/github.com/jasonroelofs/slartibartfast/1.0/ and use that path for imports. Someone should just go ahead and do it, to see how it works out - if it's popular, people will use it, and eventually it might make its way into the default distribution. The folks at Google just don't seem to see it as a problem so presumably their setup/usage doesn't hit this problem.

jjindev 13y ago
My fantasy vision, predating go, was publisher/project/version with /src and /bin below all that (separate bins and srcs). I am open to re-balancing that tree ;-), but somewhat surprised that version wasn't in from the beginning. Perhaps there were more worms in that can that I expected. (version should be constrained to x.y.z numeric form)

tyleregeto 13y ago

We use per-project work spaces too and it has simplified a lot of things for us. The biggest reason for this is that our projects aren't just Go based, their are other languages in there, many different file types. Building the project doesn't mean running "go build", that's just one component of a much larger code base. A complete build for a web application means: * compile the Go app * compiling the Sass files down to CSS * combining and minifying Javascript files * minifying HTML files * optimizing/compressing image assets * etc. These things need to happen together, and than are organized into the deployable file structure. Ofcourse this is all automated with scripts, but a single global Go workspace doesn't cut it. It assumes that the Go app is king, while in reality its just another component.

kin3tic 13y ago
How does it not? src/main.go src/_web/{css,js}/whatever.{js,css} It's not even remotely difficult and your build process is now: "go build && run_whatever_to_minify _web/css _web/js _web/img". How on earth does having assets in the Go source tree cause any complication whatsoever?

riobard 13y ago

I have similar problems building Go apps for internal use. My solution so far is to use per-project $GOPATH and `git subtree` to manage the whole $GOPATH as a single repository. The primary benefit of doing so is build repeatability: any dev can `git clone` the repo and build the app successfully after setting the $GOPATH to the repo directory. Changes in external dependencies have no affect on us until we manually incorporate them into our repo via `git subtree`. There is no need to `go get` and we avoid its associated problems (e.g. versioning, availability of remote repos, etc).

kin3tic 13y ago

Almost nothing in this article is correct. * No you don't have to manually go get dependencies of things you're already 'go get'ting * Why the fuck would you put the workspace itself in version control. That makes absolutely no sense at all. * Non Code Resources hang out in src/ just fine. You think that you BMP gets rolled into an executable file? You can, if you CHOOSE to, but no, by default, you distrib your assets next to your binary and reference them with a relative path. (Aka, the same way you do in every language/environment ever...)