C++20, How Hard Could It Be

Maybe you have a deeper understanding of the GNU GCC toolchain than I do but I'm able to link together languages with far more dramatic divergences than that.

For instance, Go and C : https://go.dev/doc/install/gccgo (it's pretty far down, let me quote: "The name of Go functions accessed from C is subject to change. At present the name of a Go function that does not have a receiver is prefix.package.Functionname. The prefix is set by the -fgo-prefix option used when the package is compiled; if the option is not used, the default is go. To call the function from C you must set the name using a GCC extension.")

I just had a small C program call a fmt.Println from a go library at my console to confirm. extern the declaration in C to match the calling convention of go, compile them to objects, then ld with the appropriate libs.

Of course you can break the friendship they can have, this is programming, that's easy to do.

This can be demonstrated with different C++ versions as well. The C/Go example was meant to show how extremely different languages can interact when you're careful enough in your build process.

In theory, a GC should never be faster than manual memory management. Anything a GC can do can be done manually, but manual management has much more context about appropriate timing, locality, and resource utilization that a GC can never have. A large aspect of performance in modern systems is how effectively you can pipeline and schedule events through the CPU cache hierarchy.

There are a few different ways a GC impacts code performance. First, even low-latency GCs have a latency similar to a blocking disk op or worse on modern hardware. In high-performance systems we avoid blocking disk ops entirely specifically because it causes a significant loss in throughput, instead using io_submit/io_uring. Worse, we have limited control over when a GC occurs; at least with blocking disk ops we can often defer them until a convenient time. To fit within these processing models, worst case GC latency would need to be much closer to microseconds.

Second, a GC operation tends to thrash the CPU cache, the contents of which were carefully orchestrated by the process to maximize throughput before being interrupted. This is part of the reason high-performance software avoids context-switching at all costs (see also: thread-per-core software architecture). It is also an important and under-appreciated aspect of disk cache replacement algorithms, for example; an algorithm that avoids thrashing the CPU cache can have a higher overall performance than an algorithm that has a higher cache hit rate.

Lastly, when there is a large stall (e.g. a millisecond) in the processing pipeline outside the control of the process, the effects of that propagate through the rest of the system. It become very difficult to guarantee robust behaviors, safety, or resource bounds when code can stop running at arbitrary points in time. While the GC is happening, finite queues are filling up. Protecting against this requires conservative architectures that leave a lot of performance on the table. If all non-deterministic behavior is asynchronous, we can optimize away many things that can never happen.

A lot of modern performance comes down to exquisite orchestration, scheduling, and timing in complex processes. A GC is like a giant, slow chaos monkey that randomly destroys the choreography that was so carefully created to produce that high-performance.

Indeed, Google's implementation of Status/StatusOr requires explicit handling of those objects, they cannot be discarded automatically.

> std::unique_ptr doesn't have any overhead over Foo* in code where semantics is the same

Not true. And you just refuted yourself by being up the ABI question. You should watch Titus Winters' presentation on this topic where he compiles code using unique_ptr and raw pointers, compares the assembler produced, and explains why unique_ptr has non-zero overhead. The overhead is indeed coming from the ABI. Google has been wanting the next C++ to break ABI but they didn't get enough votes in the standard committee.

https://youtu.be/rHIkrotSwcc

I hope we can all agree that we want the overwhelming majority of the lines of code we write, and of the cycles our programs execute, to be about solving an actual problem representing the purpose the program was written. Lines and cycles fooling with internal junk are overhead, waste.

And, we want our functions to be small, do one thing, and be easily composed.

The problem with Result and their ilk is that they pile on overhead at function-call boundaries, exactly the place where you need design to be fluid.

The great insight behind C++ was that cleanup, packaged and applied automatically, eliminates opportunities for mistakes, freeing up our attention. Exceptions apply that to error handling by running the same, well tested code when errors happen, and gathering error events to a place where we are equipped to do something useful about them.

Now that we often don't even need to code destructors anymore -- the compiler does it better -- our attention is freed for real-world problems. And, not needing to worry about propagating errors up the stack, we can focus on arguments and control moving down and results up.

Attention is easiest to manage in a small program. There just isn't as much to think about. In a big program, with many people involved, it costs a lot more to deal with extra junk, choices about how to bubble errors out. Structuring error handling into destructors and exceptions provides a common framework that burns no discussion time. Everybody gets to concentrate on solving the actual problem, without distraction by incidentals.

We would not be having this discussion if Google had not imposed its rule banning exceptions, which we know was imposed just to accommodate legacy code that did not have destructors. Now they have a thousand times as much code, still without good destructors. Wouldn't it have been less work to fix that code, then, than to impose its costs on everyone today?