Skip to main content
Preslav Rachev
Spoiler: No, for the same reason that Rust did not kill Go’s momentum either. They are different languages, solving different problems.

As you have probably heard, last week, work on an experimental successor to C++ called Carbon was announced by Chandler Carruth, who works at Google.

The project is still more of a theoretical prospect than anything one can meaningfully work with. Still, some people began asking what this might mean for the future of Go within and outside of the company.

There is some merit to that. Google is known for often picking up new shiny toys to play around with and losing interest in things it spent time and effort promoting in the past. And yet, I don’t think this is the case with Carbon and Go.

For one, they are solving very different problems. Take a look at Go. While it was originally meant to help solve Google’s C/C++ problems with its simpler syntax, memory safety, and faster build times, Go quickly proved to be a thing of its kind. Thanks to early champions like Docker and Kubernetes, Go established itself as the de-facto language for building Cloud tooling and infrastructure. But the Cloud is only a tiny part of the whole picture. Go is extremely versatile, and people prove it by creating entire businesses with it - from the server backends to the interactive Web frontend, desktop, and mobile apps.

Go proved to be a success in its own new category - a language taking a sweet spot between statically-typed enterprise-grade languages like Java, and dynamic languages Python and PHP on the other hand. It’s an 80% language - it’s neither the fastest nor the prettiest language out there. On the contrary, Go is pretty boring, making it the perfect tool for most cases.

Do you like my writing? Don’t forget to follow me on Twitter.

This is far from the world where C++ shines - the non-managed memory nature of the language and the bare-metal performance of its C core make it a perfect choice for the 10-20% of use cases where performance is mission-critical. However, this makes the language order of magnitude more complex than market contenders, and the effort of moving forward while ensuring that decades of legacy C++ code are still supported is only making things harder.

Go’s success does not change the fact that there are tons of C++ code out in the world that someone needs to keep working with. Especially at Google. I think that Carbon is Google’s second attempt to modernize its vast C++ codebase. C++ needs an infusion of fresh human capital and developer experience, and this is the central pillar of what Carbon is trying to solve. It attempts to make the field sexy and exciting for newcomers without leaving the decades of C++ legacy behind. On the contrary - those will be first-class citizens of Carbon.

Speaking about Go’s success - let me address my second and last point. To someone looking at Go right now, it may seem like its market adoption has skyrocketed since day one. However, it has taken more than a decade for the language to reach the place it is at - and this is only a tiny fraction of where it could possibly go. What I am trying to say here is that it takes enormous time and community effort for a programming language to receive mainstream industry adoption. Behind all the buzzwords and fancy constructs, if there are no actual human beings willing to invest their time and money in developing libraries and applications for it, any project will remain just a theoretical prospect. Without trying to start a flamewar here, think about your favorite programming language, the one you have always wanted to work with. Changes are, it’s not the one that’s playing your bills.

After everything I have said thus far, I am still very confident in Go’s bright future.

Have something to say? Join the discussion below 👇

Want to explore instead? Fly with the time capsule 🛸

You may also find these interesting

Consistent > Idiomatic

·2 mins

As a software engineer, I’ve learned that consistency in code is crucial for the long-term success of a project, even when it means deviating from idiomatic principles.