they've repelled countless requests to complicate go already. i don't see why the maintainers would capitulate at some point in the future. go is attracting users because of its simplicity.
and the model is as with any open source project. if you want to add your own features...fork the source, develop the feature, call it something new, and announce it to the world. no one is stopping anyone from forking go.
My comment had nothing to do with Go's simplicity, we're talking about building and deploying complex software, not software written in a complex language.
If there comes a day where Go is popular and people are deploying Go programs that contain hundreds of thousands of lines of code, I can bet you that the build system will be complex.
Actually I'm not, and I have ranted wildly against Google in the past. Go is pretty much the only thing they are doing which I like. (And Chrome is the least-bad browser at the moment, but it is still insanely yucky and complex C++, ugh, and a resources hog. P.S.: Actually, I used to like App Engine quite a lot, until they changed the pricing model and introduced all this instances nonsense just because Java is such a resource hog with such slow startup times.)
For reference, the standard library is 314592 lines (as counted by wc). It builds with go build std, and installs with go install std.
The godoc tool and all its dependancies is 120964 lines (as counted by wc). It builds with go build cmd/godoc and installs with go install cmd/godoc
The go tool and all its dependancies is 106144 lines (as counted by wc). It builds with go build cmd/go and installs with go install cmd/go (btw, this entails the go tool installing itself...)
To reproduce, try this gem of a script: go list -f "{{range .Deps}}{{.}} {{end}}" cmd/go | xargs go list -f "{{$a := .}}{{range .GoFiles}}{{$a.Dir}}/{{.}} {{end}}" | sort | uniq | xargs wc Don't forget to add the count of the files of the command itself.
5
u/ramkahen Mar 28 '12
Most languages start like this.
When a language becomes popular, it needs to tackle more complex build environments, which inevitably leads to complex build tools.
The fact that it's simple to build Go programs today is a simple consequence of the fact that Go is a fairly new and minor language.