Why ESR Hates C++, Respects Java, and Thinks Go (But Not Rust) Will Replace C (ibiblio.org)

Open source guru Eric S. Raymond followed up his post on alternatives to C by explaining why he won't touch C++ any more, calling the story "a launch point for a disquisition on the economics of computer-language design, why some truly unfortunate choices got made and baked into our infrastructure, and how we're probably going to fix them." My problem with [C++] is that it piles complexity on complexity upon chrome upon gingerbread in an attempt to address problems that cannot actually be solved because the foundational abstractions are leaky. It's all very well to say "well, don't do that" about things like bare pointers, and for small-scale single-developer projects (like my eqn upgrade) it is realistic to expect the discipline can be enforced. Not so on projects with larger scale or multiple devs at varying skill levels (the case I normally deal with)... C is flawed, but it does have one immensely valuable property that C++ didn't keep -- if you can mentally model the hardware it's running on, you can easily see all the way down. If C++ had actually eliminated C's flaws (that is, been type-safe and memory-safe) giving away that transparency might be a trade worth making. As it is, nope.
He calls Java a better attempt at fixing C's leaky abstractions, but believes it "left a huge hole in the options for systems programming that wouldn't be properly addressed for another 15 years, until Rust and Go." He delves into a history of programming languages, touching on Lisp, Python, and programmer-centric languages (versus machine-centric languages), identifying one of the biggest differentiators as "the presence or absence of automatic memory management." Falling machine-resource costs led to the rise of scripting languages and Node.js, but Raymond still sees Rust and Go as a response to the increasing scale of projects.
Eventually we will have garbage collection techniques with low enough latency overhead to be usable in kernels and low-level firmware, and those will ship in language implementations. Those are the languages that will truly end C's long reign. There are broad hints in the working papers from the Go development group that they're headed in this direction... Sorry, Rustaceans -- you've got a plausible future in kernels and deep firmware, but too many strikes against you to beat Go over most of C's range. No garbage collection, plus Rust is a harder transition from C because of the borrow checker, plus the standardized part of the API is still seriously incomplete (where's my select(2), again?).

The only consolation you get, if it is one, is that the C++ fans are screwed worse than you are. At least Rust has a real prospect of dramatically lowering downstream defect rates relative to C anywhere it's not crowded out by Go; C++ doesn't have that.

Comments

In defense of C++

[Dutch Gun]

The reason we have to say "don't do that" is because C++ remains compatible with C and older version of C++. There are literally billions of lines of existing C++ code out there, and the language committee realizes it can't just snap its finger and order everyone to rewrite all that old code (which is stable, functional, and debugged, btw) because we have something newer and better now.

It's pretty straightforward to write safe, new C++ code if you understand how to use the new features and abstractions. I wrote an entire game / game engine recently using modern C++, and it's amazing how few bugs I've had thanks to recent language improvements and techniques.

I'm not sure where this "large projects can't enforce code discipline" idea comes from. What does he think "coding standards" are, which nearly every major company, organization, or project has? And if someone doesn't understand how to use a smart pointer instead of a raw pointer or avoiding class inheritance hell at this point, then really, they shouldn't be contributing to your C++ projects.

I get it that some people dislike or distrust C++. It's a complex language that's hard to master. They don't like that it makes a lot of compromises in the name of practicality, but that real-world practicality is why many of us use it for large, performance-critical real-world projects. I'd never argue that C++ is the right language for every project. In fact, it's a fairly specialized language at this point. But that level of hyperbole is a bit annoying.

Re:In defense of C++

[Dutch Gun]

No computer language is going to help a project programmed by idiots.

Indeed. C++ is a better C

[Anonymous Coward]

Take the low-level access provided by C, and then add the ability to construct both compile-time and run-time abstractions to an incredibly high level, but with as little cost as possible. That's C++.

C++ is an amazing achievement.

Every academic language approaches Lisp, but every practical language (you know, the ones that actually make the world turn) approaches C++; Bjarne said as much, and he was right.

Re:Well, don't do that!

[TheRaven64]

Sorry, I should have been more explicit. Messages sent over channels establish a happens-before relationship, but not with respect to any other memory operations. Everything else is non-atomic. That's fine in a language like Erlang, which doesn't allow mutable shared state (in Erlang, the only mutable object is the process dictionary, which cannot be shared), or Pony (and, I think, Rust) where the type system guarantees that no object is both shared between threads and mutable at the same time. In Go, the language makes it easy to share pointers to mutable objects, but then doesn't provide any guarantees about ordering or synchronisation for accesses to them.

Go tells people to 'share data by communicating', which basically means that you shouldn't share mutable data you should share channels that are used to serialise operations on mutable data. That's fine as a programming model, but the language provides absolutely no help (either in the type system or the tooling) to ensure that code actually follows this model. If ESR's complaint about C++ is that it requires programmers to follow 'well, don't do that' rules, then he should hate Go, because the only way of using it to write correct programs is to carefully avoid doing something that the language makes easy to do accidentally. At least with C++, it's relatively easy to audit code for violations of the C++ Core Guidelines. It's practically impossible to audit Go code for sharing of pointers to mutable state (in the general case, Go's subtyping model means that it reduces to the halting problem, in the common case it's just really, really hard).

Drivers/Firmware

[zifn4b]

How do I write drivers and firmware in Go? I think C is going to be around for awhile.