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

Re:business code

[friesofdoom]

I dont think ac has a grasp on how many times google has pulled that trick before xD

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).

Re:Vectorization

[shatteredsilicon]

I tested this extensively, including quite recently, and unfortunately where intel's C compiler as far back as 2008 produced excellent results (all the loops in my code vectorized even back then), GCC to this day fails to vectorize most of them. last time I tried with clang (last year), it fared even worse than GCC.

Re:Well, don't do that!

[roca]

Mozilla has run a very large-scale C++ project for many years, with an elite team of developers. Mozilla makes extensive use of enormous test suites, static checkers, Valgrind, ASAN, TSAN, etc. Mozilla created Rust because we concluded C++ was not reliable enough or secure enough for large-scale multithreaded applications.