Lots of exciting news weekend. No, I’m not talking about March Madness. Go is finally getting support for Protocol Buffers. While this project doesn’t really have any impact on me, since I’ve not an avid user of protocol buffers, it does hint that people at Google are actually starting to use Go.
When I was at Microsoft, I tried to use F# as much as possible. One of the most useful features of F# was that it came with a REPL shell - which basically gave you a console where you could execute .NET code. The only other way to do it was to use Powershell, which I never liked too much. This let you test any .NET libraries you wrote, even stuff you wrote in F#.
At that point, F# project was still young, and there were lots of bugs. But there was a strong community of employees inside MS that used it for real work, and you could see the product continually improve. It’s now the first functional language in Visual Studio.
I was hoping to see a similar pattern with Go. Since it launched in November, however, only a fraction of the contributors of Go worked at Google (20 total, or about 10% of the total contributors). If you assume that Google as a whole has 10000 developers, roughly 0.2% of of them were active in the project.
Also, there are some nasty bugs in the language that make it unsuitable for network-heavy computation. Issue 631 especially worries me, because any Go program that repeatedly opens or accepts networks connections (like a web crawler or a server), will leak memory. These are exactly the kind of programs you’d write at Google.
So that’s why I’m happy to see protocol buffers for Go. Like the F# Visual plugin did for MS employees, I’m hoping it will let Google employees to use it for some cool internal projects. And before you know it, I’ll be running my Go apps inside AppEngine.