Go: reasonably high level programming, but with performance

Standard

I’ve always thought that it should be possible to design a language that is both usable and performant. JavaScript performance has improved tremendously, but it is still quite a distance behind C and even Java. Of course, programmer productivity is certainly more important than raw performance for most applications. It’s only as you try to scale up services that you really wish you could squeeze out more performance. In fact, being able to squeeze out more performance is one way to avoid the complexity shift of moving from one box to two/many. Of course, there’s always an upperbound to this, but that upperbound can be remarkably high.

I always thought that D looked like the language that could unify high level programming and performance. But D has failed to catch on and seems to be in a state that would make anyone seriously question using the language for real work.

Now, along comes Go, a new language sponsored by Google. More interesting than the Google part, is that Go was created by people with a long history dating back to the origins of Unix (Rob Pike, Ken Thomson, apparently even Brian Kernighan are involved). The language is designed to support super fast compilation (yay for programmer ergonomics!) and C-like performance. Importantly, the language also has built in features to help support scalable and safe concurrent programming, via “channels” for passing data back and forth, rather than something like transactional memory.

Go has a simplified object model that looks cool, but I’d be curious to see how it feels to use in practice. Go doesn’t have exceptions, which seems like a real drag to me. Apparently, exceptions are still considered an open issue and they present thorny issues when you’re dealing with concurrent processes.

Go’s standard library looks to have a decent collection of features, and you can call C code pretty easily. More care needs to be taken if you want C code to call into Go. If Go can get its packaging story together more quickly than Python has, it may indeed start having appeal as a high-level, fast, concurrent programming language.

It’s still very early for Go. It’s not used in production in Google yet. It doesn’t run on Windows. But it has arrived on the scene hitting many points at the “good enough” level (fast compiler, decent library, ok interface to C, decent docs). Google has full-time staff assigned to it, and they’re even hiring a program manager. With speculation that Google doesn’t want to use Python for their high volume services, I wouldn’t be surprised to hear that Google really wants to use Go internally. With an “anchor tenant” like Google, Go has a lot more potential than D ever had.

Now they just need to deal with the pesky issue of the name.