My posts on Google’s Go (Part 1 and Part 2) definitely touched a nerve with a few folks. And I appreciate good dialog on ideas like this…
One pervasive question that I keep hearing is “Who is Go good for?” And I’m having a hard time finding a good answer. Even Go’s own FAQ page is uncharacteristically vague about it.
I’d say there are plenty of non-starters to keep Go out of the application programming space. After my arguments pointing out that it won’t replace Java anytime soon, folks are telling me that I wasn’t looking at the right demographic. These people suggest that Go is really for systems programmers. Systems programming has typically been the bastion of C and (more recently) C++ programmers for the past 2 decades. If you’re doing serious systems programming, you’re in one of those two camps, generally speaking. Maybe with a touch of assembly here and there.
OK, I’m game for looking at that. First off, what makes a good systems programming language? Here are few things we might want:
- can operate in resource-constrained environments
- is very efficient and has little runtime overhead
- has a small runtime library, or none at all
- allows for direct and “raw” control over memory access and control flow
- lets the programmer write parts of the program directly in assembly language
Does Go really fit into that box?
- Go’s performance numbers are rough 6x worse than C++, on average. The best performing Go test was comparable to the worst C test. While I gave Go some leniency with Java on performance in an application environment (there are plenty of other non-memory, non-CPU bottlenecks to worry about there), the systems world is far stricter about raw, unabashed execution time and resource consumption. (+10/20 pts)
- Go’s memory and execution footprint are higher than C and C++, according to these stats. Not exactly an ideal candidate for replacing either of these languages currently entrenched in this space. An interesting experiment: Compile Hello World in Go and C++. Go’s compiled & linked output: 38K, C++ clocks in at 6K, about 84% smaller. (+10/20 pts)
- If you include the garbage collector, the Go runtime footprint is certainly larger than C/C++. But it’s safer than either C/C++ for the same reason. And to top it off: Go’s garbage collector isn’t parallel safe right now. (To be fair, that’s the #1 thing on the TODO list right now for the Go team) (+15/20 pts)
- Raw and direct control is possible, so Go checks in fine here. You can use this to investigate runtime structures if you like. (+20/20 pts)
- This is similar to Java’s native interface (JNI), but statically linked. So yes, it’s possible. (+20/20 pts)
At 20 pts per question, let’s be kind and give Go a 75/100 possible score there (A solid “C” on the American grading scale, yuck yuck…). If you’re a C/C++ programmer where you’re already at 100/100 on the above chart, where is your motive to switch here? Couple that with the fact that systems programmers are not exactly known for adopting bleeding edge technology at a rapid pace. It was years before C++ ever made substantial inroads with the embedded C crowd. Considering the degree of reliability required to do high quality, bare-metal systems programming, I’d be skeptical of anything new in this space too.
Finally, let’s hit up the syntax argument one more time, because I think this is the crux of the entire problem. Before I do, let me just say I don’t personally have any problems with Go’s syntax one way or the other. I’ve learned a plethora of languages in my tenure as a software nerd and adding one more would not be a big deal if I felt the payoff was big enough. But I think syntax familiarity is a barrier for a lot of people, based on my experience as a language instructor and Parkinson’s Law of Triviality.
Briefly stated, Parkinson’s Law says we unfortunately spend disproportionate amounts of time and energy arguing about things that are more trivial (and we understand) than we do about those that are more substantial (and fail to grasp). This is particularly true with programming languages and syntax. I saw that resistance teaching Java to C++ folks back in the mid-90s. And that wasn’t exactly a big leap. Changing from C++ to Go is likely to be much worse than C++ to Java, and that resistance is critical to adoption rates.
So I’m not feeling the love for Go replacing C/C++ systems programming either. If I was looking for a new tool in my toolbox, I don’t think I’d be buying this one from Google.
All of this leaves me scratching my head and singing:
“Go! Huh! Yeah!
What is it good for?
Absolutely nothing.
Say it again.”
This article is translated to Serbo-Croatian language as well.