Why C++ Programmers Haven't Flocked to Go

Published: 2019-05-27

Tagged: software golang thoughts

Rob Pike once remarked that what surprised him about Golang was how few C++ it attracted. For a long time, this thought lay in some dusty corner of my mind. Then, the stars aligned: I found myself working in C++ alongside long-time C++ programmers, and, at the same time, I was picking up Golang (again) and building little toy projects on the side.

Having used Python for the past few years, jumping into Go felt natural. The simplicity, sane defaults, and few gotchas helped to quickly build momentum. The small size of it's standard library and emphasis on composition are refreshing and exciting after spending one too many days hacking through a jungle of complexity. On top of that, the quality of tools for testing, formatting, and managing dependencies makes them a pleasure to use. The biggest challenge in learning a new language is figuring out the path of least resistance to getting things done - the best practices. All of the features listed above made it easy to read pieces of open source projects and pick up good habits.

Learning C++ was the complete opposite. I got the C++ Primer, which at close to 1000 pages is more than twice as long as The Go Programming Language. After exposing the reader to arcane topics, many disorienting ways of doing things, and all the defaults that are actually traps, the usage of "primer" in the title seems like a cruel joke. Despite spending roughly twice as much time on this endeavor, I doubt I got much out of it, at least in terms of being able to build things. At least I found out why C++ programmers aren't all flocking to Go.

These languages were designed to solve different problems, which has led to the growth of two very different communities of users. The most visible trait of the Go community is its focus productivity. All the features I listed earlier? They help in iterating faster and getting a working product out the door sooner. On the other hand, the most prominent trait of the C++ community is its obsession with performance. Folks here talk about shaving off microseconds of execution time or about using memory more efficiently. I admit, the latter group has me often scratching my head trying to divine how saving a few hundred megabytes of ram is worth the extra development time. The values permeating these cultures are so opposite that it's no wonder why there's little conversation happening between them and even less conversion from one camp to the other.