I don't want to waste time chasing a rabbit, so as Tahir mentions, the folks behind Go should make it a worthwhile venture. But there are lots of accomplished people out there who are doing insubstantial work. Prior feats of those involved are not enough for me and brings me back to the salient factor: static-linked binaries. I could build a small project, deploy it, and monitor its reliability. It would need to serve enough purpose to stand the test of time, and not fade away; a "middle ground", if you will. Web applications massively thrive or quickly fade, and I bet there is room for something in-between. I would find comfort there and it would encourage diversity and free expression. Software doesn't have to be either the empire or the rebellion.
I want to express myself with the best tools available, but not at the expense of my expressions. I have much to contribute, and little time to do it. More than express myself, I want to build great things. I've chosen software to help me accomplish that. Sophisticated tools are prone to malfunction if they are not routinely maintained and I've found that many of my creations do not stand the test of time, and I want them to. If Go can bring more persistence to my creations, it will be useful to me. This is my rationale for taking the time to build something in Go and observe its wherewithal over the ensuing years.
I built a simple CGI binary in Golang this weekend and the experience was highly positive and I'm planning to delve further into it soon. For now I'll briefly share my notes:
My next steps:
^1: Passenger and the Ruby Enterprise Edition helped out a lot with Ruby and Ruby on Rails memory management and performance by sharing dependencies across multiple web apps and forked processes. Bundler inhibits those optimizations by not sharing any dependencies.