Why I don't want to use Go

http://arantaday.com/why-i-dont-want-to-learn-go 

 

 

There has been a lot of excitement about Go's upcoming 1.0 release - but I'm going to express a controversial opinion: I don't really care and have no intention of using Go.

I'll grant that C is sometimes painful - I've often searched for a more 'modern' systems-level language (with built-in decent implementations of standard datastructures, a well defined memory model, cross-platform abstractions for things like I/O and concurrency, saner imports, and a type-system strong enough to not require constant casts). D was fragmented last time I looked, so C++ seemed like the obvious choice, and it's perfectly workable as long as you limit yourself to the sane parts (although, I never really loved it - it's too big and complex, and has too much C-cruft hanging around).

So, when Go was first announced, I was excited. Who wouldn't be by the prospect of a new language for systems work by Pike, Thompson, et al? But after a few days of playing, I had trouble figuring out what niche Go is supposed to fit into.

For 'high-level' work where performance doesn't really matter, I tend to use Python (others prefer Ruby or Perl, but you get the idea). They're great for things like web-frontends that easily scale horizontally or one-off scripts.

For 'mid-level' work, where performance is important but I'm not willing to sacrifice all ease of development, the JVM languages are my goto (although, I sometimes fall back to Haskell/Lisp/Python if I need native interop and JNI is too expensive).

Finally for low level work, where nanos/micros matter, C or C++ fit the bill (no unpredictable GC pauses, no huge object overhead, etc).

So, where is Go supposed to fit?

I'll gladly acknowledge Go is a far better C, with garbage collection. But the GC makes it unacceptable for the only types of problems I'd ever consider using C for. And if I'm willing to put up with a GC, I'd always prefer Java/Scala/Python/Lisp/Haskell over Go for any problem I can think of.

And before you tell me that the GC isn't that big a deal: it is. Literally every big project I've worked on in a garbage collected language reserves a bunch of memory off-heap at startup and uses that for allocations on the critical path because the GC kills performance. Greplin's index servers, HBase's region servers, Signpost's realtime learning systems, ITA's fare finders, and others I probably can't talk about publicly *all* do this because they need to (trust me, no one *wants* to write a slab allocator and reference counting system if they can avoid it). The Oracle JVM's GC has had man-centuries of dev time put into it, and it still is too slow for every performance-critical project I've seen. Take a look at the performance improvements HBase saw by moving some allocations outside of the GC's domain.

I think the only way for Go to gain traction is to directly confront, and best, either the high-level languages or the mid-level languages. And, frankly, I don't see either of those two things happening.

PS: Follow me on Twitter (@smanek) if you're interested in JVM/Concurrency/Distributed Systems