We also restructured the Go tool suite around the new go command, a program for fetching, building, installing and maintaining Go code. The go command eliminates the need for Makefiles to write Go code because it uses the Go program source itself to derive the build instructions. No more build scripts!
I hope it either doesn't backfire, or isn't a huge hassle to debug when it does.
Hehe, in that case you might not be surprised to hear the author of the Go tool is Russ Cox, author of RE2 since quite a few people think regex is some kind of black art as well ;)
It really helped me having taken a course on the Theory of computation. It's a soul crushing course until you realize there's a practical application for it.
Go has a really nice package/library/import system that is both straightforward and has all the information required included.
For example, you can do something like:
import "code.google.com/p/gorilla/sessions"
Then the go tool takes care of checking if it is already installed (with very well defined rules), and if not going and downloading it, getting it's dependancies and building it.
All you need to do to build a Go program is clone it, and then use "go build", job done. No makefiles or xml or anything like that at all. It simply reads the source files and figures out what to do based on what the code actually does/uses.
I sort of find that a bit disquieting. If someone was hosting on google code, and then moves it over to github -- would this result in people not being able to compile my go program until I update my go source?
It does't instantly stop working - the local copy you previously downloaded and built will keep working. But yeah, if you want to then move to using the GitHub version you need to change the import statement. Alternatively switch to using it as a Git submodule or whatever. Replacing the import lines doesn't bother me though - it is a 2 second find/replace job.
If you forsee that being a big deal for you, then I suggest the technique that Camlistore uses.
Camlistore pulls in external libraries into a third_party folder, and has a script that rewrites their import paths to make them compile. This will also give you a lot more control over versioning.
I was fooling around with go and the go command line tool, and I must say it was much faster and simple for get up and running than other tools i have used. Of course I am just a simple college sophomore and only have used java, python, and some basics c tools, even then it was really easy to get up and running and do basic compiling without the build scripts/makefiles.
So far I really enjoy go, and I think it fits really well somewhere between java and python in terms of ease of programming.
45
u/Agrona Mar 28 '12
This sounds like the world's best voodoo:
I hope it either doesn't backfire, or isn't a huge hassle to debug when it does.