“Within C++, there is a much smaller and cleaner language struggling to get out”
– Bjarne Stroustrup, creator of C++ in The Design and Evolution of C++

Developers are talking about Google’s latest creation: Carbon, a supposed wunderkind programming language that will save the technoverse from C++ and serve as its successor or replacement. Just like a rehashed Hollywood blockbuster about a supposed messiah, we’ve heard this story before. The 2000s saw more than one language try to fix C++’s minuses. The two big ones were Rust (backed by Mozilla) and Go (a.k.a. Golang, initiated by Google).

We should note that Google had been working on the Carbon programming language for at least two years before announcing it. The oldest pull request in the Carbon git is from April 30, 2020. Google’s team has embedded a lot of work into the repository already, including detailed outlines of the philosophy and goals for portions of and the entirety of the project.

History Threepeating Itself

C++’s creators had their own goals: to build in higher layers of abstraction into C. They took on immense amounts of “technical debt” from C, ensuring C++ could be backward-compatible to compile C code. But over time, accommodating that with feature after feature made C++ overly complicated. Now, building on decades of experimentation and backward compatibility, C++ just literally might be the most convoluted language out there.

That got a lot of developers motivated in the 2000s to fix the new problem.

Google conceived of Go as a replacement for C++, the same motivations behind another major language: Rust. Go’s initial approach was celebrated: something straightforward, easy to learn, and simple to understand. When Go and Rust were both production-ready, Go could tout that simplicity against Rust’s extreme learning curve. Additionally, the performance advantage Rust could claim over Go wasn’t worth the tradeoff to many developers. Rust sacrificed compile time for runtime, for instance.

So are we about to go reiterate this process (tri-iterate? “three-iterate”?)? 1) C → C++, 2) C++ → Go, 3) Go → Carbon?

Well, yes.

Go has failed to replace C++. But WHY? Why did it fail? And why did Google feel that the best way forward was to create another new language to get around it? Here are the major reasons:

1. Go-C++ Interoperability

Anything taking over for C++ has to at least work with C++. While the cgo API is definitely there, using the two together is not that much fun.

For most practical use cases, you will find yourself wrapping your C++ code with a C API (it is called CGO after all!) which can amount to a fair amount of boilerplate code.

Along the way, you are going to lose some type safety, proper destructor support, and have to work around memory management. Add to that the fact you will likely find yourself writing an abstraction layer on the Go side. Before you send it through, you are quite likely to end up with a Frankenstein project, just like this team.

2. Interoperability Paradigm Shifts

Go has a peculiar, but highly efficient, concurrency model focused on goroutines. Using user mode scheduling along with miniature, dynamically growing stacks will get you a level of parallelism you can only dream about in other languages.

Unfortunately, this magic is utterly unavailable for your C++ code, meaning every cgo invocation goes through a move from a mini-stack to a full-blown stack and back again. As you might guess, this is quite heavy on performance, making every invocation a significant burden.

Working around this limitation to keep your interoperability API efficient will likely make it even more complex and cumbersome to use, while winning you some additional boilerplate code to write.

4. Go’s Runtime

Go has a fairly large and complex runtime, which makes it less desirable than C++ in many use cases. While the runtime comes with a lot of magic tricks such as best-in-class garbage collection, it’s not without its baggage. While you can hardly compare it to the Java Virtual Machine languages or .NET runtime, it’s not something you can easily fit into embedded devices, operating system kernel mode, or other similar environments.

5. Pointers are Important

When writing system-level software, raw pointers are a key element in getting the best performance from your hardware and operating system. Whether you are offloading encryption to the CPU, checksum calculations to the network adapter, or memory operations to the DMA controller, you need easy access to the underlying memory.

Go’s approach for pointers and direct memory access is far from its strong suit, which can make writing encryption, networking, or storage software a headache.

What Carbon Will Try to Do

What does Carbon want to do differently to ensure it succeeds as an adequate C++ successor where Go failed? They’re going to tie the two languages together as tightly as possible with as little bridge code as possible as well. And as a caveat, Go did succeed in some things, such as being easy to learn. Carbon’s builders plan to emulate that.

Related goals include minimal bridge code between the two languages, support for basic C interoperability, support for advanced C++ features, and mixing the two languages’ toolchains.

1. Quick adoption: It’s supposed to be a piece of cake for C++ developers and easy to work with immediately for C++ applications. Replacement for C++ isn’t a snap process, but it can be made relatively quicker.
2. Bidirectional interoperability with C++: Packages and libraries made for C++ will work for Carbon, and libraries or packages made for Carbon will work for C++. A formal Carbon-C++interoperability layer will access certain C++ APIs from Carbon and vice versa.
3. Memory Safety: You have more control over memory safety so you don’t have to compromise on things like compilation time like you have to by default in Rust. You can run in three modes: debug, hardened, and performance. C++ enables uninitialized variables which can later cause memory access bugs.
4. Generics: C++ relies on templates to support parameterized types, but they can be complex. C++ templates also bog down compile time. Generics, in C# for instance, work in runtime. The idea behind Carbon generics is to check function calls independently, send earlier error message when necessary, and speed up builds.
5. Memory access: Carbon kept the basic concept of pointers’ value while giving up on most of their complexity. Carbon gives you the two most basic operations of derefence and address-of, to make your life easier.

Wait and C

Google first announced Go in 2009, but the language didn’t hit full production readiness until 2012 (at Rookout, we added production grade support in 2021. Thanks for waiting!). Expect a similar amount of time between now and Carbon’s production readiness. And yet, being backed by Google will likely make Carbon a contender in the A-league of software languages, not to be known merely as C++’s substitute. In its early days, developers should still expect to write Carbon code in a text editor and do things the hard way, but if Carbon grows as planned, that might not be necessary for near-to-mid-future classes of devs. But then again, it might end up like D.

Rust and Go in some ways are polar opposites. They are defined by their respective approaches to code. Rust is scrupulous, meticulous, and demands painful attention to detail; Go is laidback by contrast, easygoing, and simple. They both prize efficiency, but one in the means (Go) and the other in the ends (Rust). A true Go vs. Rust battle needs to compare the two languages in more depth.

Golang and Rust owe their births to loathing for other systems languages (and by languages, I mainly mean C++). Mozilla backed employee Graydon Hoare’s side-project for a C++ alternative, which became Rust. Google designed Go to improve productivity and simplify development.

Go vs. Rust: They’re not so different if you pretty much ignore everything about them

But the languages treaded on two very different philosophies to build themselves out. Rust’s creators wanted to improve resource control, security, and concurrency. They achieved this by creating a complex programming language, but one that is indisputably one of the fastest in popular use today. Go went for accessibility, achieving similar goals like high concurrency while gaining a rep for being one of the easiest languages to learn.

The difference in complexity is the main determining factor for a lot of projects – the simpler the code, the simpler the development. But that isn’t the only reason to choose one language over another. This overview will compare and contrast Go vs. Rust with a focus on debugging and observability. We’ll review the most common points of comparison between the two before going into the different options for troubleshooting, debugging, and gaining visibility into apps built with either of the two languages.

Learnability

There’s an absolute contrast here. The languages treaded on two very different philosophies to build themselves out. You can see the difference in how they say “Hello.” Go has only 25 keywords while Rust at the time of writing has 39 keywords (with another 13 reserved for future versions).

Rust’s creators wanted to improve resource control, security, and concurrency. They achieved this by creating a complex programming language, but one that is indisputably one of the fastest in popular use today.

// Hello World! in Rust
fn main() {
    println!("Hello World!");
}

rustc hello.rs

$ ./hello
Hello World!

Rust also uses some different names for key concepts. It refers to its packages as crates. It also relies heavily on macros – macros are pre-processed versions of functions, while functions are compiled, so they involve no runtime. Languages like C, Lisp, Scala, Erlang, and Elixir also use them.

On the flip side, Go went for accessibility, achieving similar goals like high concurrency while gaining a rep for being one of the easiest languages to learn.

//Hello World! in Go
package main

import "fmt"

func main() {
    fmt.Println("Hello World!")
}

Go does not support macros, but rather constants. The idea is the same – to call a consistent function or value – but the key difference is here:

Rust’s macros are pre-processed. Go’s constants are compiled by the compiler.

Goroutines vs. OS Threads

Go is also notable for its use of a lightweight kind of thread called Goroutines. Goroutines are the most notable example of something called green threading (or virtual threading). They’re designed to work like multithreaded environments but can operate outside of environments that don’t support native threading. VMs or runtimes handle scheduling in green/virtual threads.

Just the same, Goroutines operates with one runtime. But, there being less system overhead because they are managed efficiently by the user-space Go runtime, because they don’t rely on operating systems, helps Go with fast start-up times and fast clean-up times. Additionally, they’re considered incredibly easy to use by simply calling the given functions with the keyword go.

//Seriously a goroutine is this simple
go functiontocall()

Goroutines are particularly efficient because they also allow coordinating data using channels, which can balance the activity of each Goroutine to clamp down on latency.

Rust takes the more traditional approach. To avoid adding overhead by using a runtime, Rust actually dropped native support for green threads and switched to operating system threads early in its history. By default, Rust uses a 1:1 model – one operating system thread to one language thread. As per usual, there are many crate options for using some other kind of model.

Memory Safety

There’s no rust on Rust’s memory. Poor puns aside, Rust has a tremendous emphasis on memory safety and Rust won’t allow for unsafe use of memory during compilation. The practical reason behind this is because most memory errors occur in production and often lead to vulnerabilities; this preempts that.

All data inputs have to have been initialized before use. Rust also doesn’t permit null pointers or dangling pointers.

Go is also considered a memory-safe language, but not to the extent that Rust is. Go also blocks dangling pointers and limits memory leaks.

On memory space, Go uses garbage collection while Rust uses something called ownership and borrowing (every object is owned by someone, who can then lend it out).

Go’s garbage collector periodically works in the background to free up data once you hit some pre-specified value. This will add to system overhead though.

Compiling Go vs. Rust Compiling

That complexity makes the difference when the code compiles. Go compiles straight to machine code, cutting out “middle men” like virtual runtimes or other mid-level interpreters. Other factors, like how Go dependencies work, definitely help with compilation speed.

Rust has made improvements over the years, but still can’t stand up to Go. Nicholas Nethercote, a former engineer at Mozilla, kept detailed notes on the issue and notes continued improvement on benchmarks year to year. See this example of Rust benchmarks in 2019.

Spider-Man compiling Rust instead of fighting crime

Rust sacrifices on compile time in order to achieve strong performance later. Rust’s memory safety implements certain things during compilation time to protect the code from bugs and vulnerabilities. Rust’s macros are precompiled. Rust’s legacy issues related to single-threaded compilation, build scripts, and periodic code generation for individual crates also contribute to slow compilation according to Brian Anderson’s extensive review of the problem, but they are all part of the plan.

That being said, Rust allows for more control of the build process. That might make compilation a longer process, but what comes out on the other side will be far more efficient when running.

Go doesn’t allow for that kind of control automatically. Go’s build tags give you a little control by specifying tags that will decide which files to include and preclude from the build process, however this doesn’t come close to Rust’s compilation customization abilities. Here’s an example with a build tag at the top of this

//+build helloworldtag
package main

import "fmt"

func main() {
fmt.Println("Hello World!")

Include the file in the Go build process with this command:

go build -tags=helloworldtag

Go vs. Rust Debugging: What Do the Devs Prefer?

Go and Rust can be quite different philosophically, but they have similar options for debugging. That being said, they have several options at that. Both languages see large numbers of users leverage print statements, logging, open-source debuggers, and IDE tools to do the job. Here is a quick rundown of the main ones:

Rust Debugging

With Rust, you can use print statements [println()], logging at the debug level, or the standard built-in dbg tool to exterminate bugs in your code. Logging carries with it a constant struggle with verbosity (which is the same in other languages): How much data is too much data? Will it make tracking down the problem even harder?

This debug! macro example is partially modified from the one appearing in the Rust docs:

use log::debug;

let pos = Position { x: 3.5, y: -1.5 };

debug!("New position: x: {}, y: {}", pos.x, pos.y);
debug!(target: "location", "New position: x: {}, y: {}", pos.x, pos.y);

There are also several IDEs popular among Rustaceans, but the presumably advanced IDE tooling seems to play second fiddle to the simpler options. In fact, surveys show just that for Rust developers. JetBrains’ own developer surveys showed just that for all segments of IDE users different groups of devs. Some used VSCode, a JetBrains option (IntelliJ IDEA or CLion), and VIM.

Visual Studio Code, CLion, IntelliJ, VIM, and Sublime Text are the most common, with VSCode being the #1 choice for 40% of Rustaceans. Keep in mind though that that number comes from a JetBrains survey of its users, so the numbers for CLion and IntelliJ might be slightly higher than a true average. That being said, CLion and IntelliJ probably do represent a massive chunk of the Rust IDE marketshare.

Go Debugging

Gophers, if you will, actually widely prefer print statements and logs for debugging also, according to a survey by Golang‘s own website. Other features like unit testing and the PANIC output were the next most popular ways to debug Go. About 54% used special debugging tools like Delve or gdb on a local machine. A lot less find Go remote debugging useful, at 16%, indicating that even for simpler syntactic languages, remote debugging can be an issue. While Go is an efficient way to get programs to run smoothly and save time, it’s still bogged down for cloud-native options.

Go uses three kinds of print statements using the fmt package: fmt.Print(), fmt.Println(), and fmt.Printf(). You can also use the first two without the fmt package. When it comes to logging, the issue is the same as with most languages, in that it can lead to information overload.

That being said, Go provides a couple of extra log levels not common to other languages via logrus. Altogether, these are the seven Go logging levels: TRACE, DEBUG, INFO, WARN, ERROR, FATAL, and PANIC.

A common log at the debug level might look like this:

package main

import (
log "github.com/sirupsen/logrus"
)

func main() {
log.SetFormatter(&log.JSONFormatter{})
log.SetLevel(log.DebugLevel)
//To ensure debug logs print with other logging levels, you need the above line of code
//Such a line isn't needed for other logging levels

log.Debug("Debugging message.")

}

In terms of IDEs, there’s a similar selection like Rust for Go users: VSCode, VIM, Emacs, and Atom. JetBrains also has a specialized IDE called GoLand (many surveyed also said they used IntelliJ for Go). It’s not exactly clear what the most popular IDE in the community is.

The two above mentioned surveys are flawed on this question. JetBrains surveyed many of its own users to find 59% preferred GoLand to others; Go found a majority favoring VSCode, but they reached survey takers through a VSCode promo (to be fair, JetBrains and go.dev both admit the issue in their questionnaires). You can see our other post to read more about Go debugging.

Go vs. Rust in Popularity

On a final note, it might be interesting to look at how much developers actually work with (and like to work with) either language. Rust ranks at the top of the list in the annual Stack Overflow survey for most loved language, up there with Clojure, Elixir, TypeScript, Julia, and Python. But Go is high up there also, in 8th place.

On top of that, Rust is the most wanted language by devs who want to work with or learn something else. And Go? Right behind it at 4th place.

Of more than 70,000 devs surveyed, only 11% reported having used Go. But 9% reported using Rust. When you break down those numbers further, you find a very big difference between pro devs and current students. More programmers in training have used Rust (7%) than have used Go (5%)! Could this be a sign of things to come? Are more students skipping the easier languages assuming they can circle back and learn those later? This blog doesn’t have the answers to those questions, but the close numbers between the two in these surveys certainly make comparing them even more interesting.

Conclusion: Go vs. Rust

Go and Rust offer a lot to programmers. They are definitely both products of their time, but reflect that the developer community is itself diverse, seeing divergent paths for going forward. Both languages have their advantages, and both offer some diverse approaches to observability generally and debugging specifically. Both could do though with more advanced options to cope in cloud-native and microservices environments.

If you want to hear the latest from Rookout, sign up for product updates with our monthly newsletter!