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++

[TheRaven64]

I've recently started using C++ for a bunch of things where I would previously have used a scripting language. It has basically everything I want from such a language:

• Closures (including compile-time specialisation with C++14 auto parameter lambdas).
• A rich set of collection classes (written by people who actually care about performance).
• Regular expressions.
• Smart pointers (so I don't need to think about memory management)
• Futures / promises and threads.
• A tiny dependency footprint (so my code will run on pretty much any *NIX system)

Most of the time, I can compile at -O0 and run in less time than it takes the Python interpreter to start and if I find that performance actually does matter then I can quickly profile it, find the bottleneck, and replace it with something a lot more efficient.

Well, don't do that!

[TheRaven64]

Arguing that it's harder for large-scale projects to manage a 'well, don't do that' approach implies that he's completely missed the last 40 years of tool development. This is much more of a problem for small C++ projects than large ones. Large ones have pre-push hooks that run static checkers that enforce rules like no bare pointer and no operator new / delete. It's the smaller ones that rely on programmer discipline to do this that are more likely to have problems.

Go is a horrible language. It has multithreading as a core part of the language, but no memory model and no type system that can express notions of sharing or immutability. The designers clearly realised that generic types are important, and so added precisely one to the language (the map type, which is parameterised on the key/value types). It has a map type that maps from one object type to another, but no way for users to define what equality (or ordered comparison or hash) means on objects.

Re:Well, don't do that!

[K. S. Kyosuke]

I thought the idea was that sharing a reference to mutable data over a channel guarantees that all writes to the shared data by one goroutine are safely in memory before the recipient starts working with said data. There seem to be some extra operations for locked or atomic operations with shared values but the language seems to be pushing people into operating on shared data using workers that use channels to hand off ownership. There may be limitations to that approach, and nobody is checking automatically that you don't do something that you shouldn't be doing, but at least the space of good and bad things to do seems vastly simpler than in case of C++. Certainly it seems that working properly with ownership hand-offs in Go in most situations is easier than, say, working with dynamic memory management in C in most situations, even if it still depends on people not doing something stupid intentionally.

Vectorization

[shatteredsilicon]

The big problem when it comes to using anything other than Fortran, C or C++ is that 20 years after the first MMX and SSE instruction sets have been added to CPUs, there are only a handful of compilers that known how to vectorize even loops that are hand-crafted to be vectorizable - and the ones that can do it are all commercially licenced (GCC might theoretically have some support for it, but in reality it doesn't vectorize most things). And since most of the performance advancement in silicon has for a long time now been focused in SIMD units, that means that for any performance sensitive workload there are no feasible alternatives. If it has taken GCC 20 years to get not very far, how long will be be before much younger compilers get anywhere with this performance critical feature?

Re:Vectorization

[TeknoHog]

Agreed, but I'd like to take a step back. IMHO, it is idiotic to first write a loop and then vectorize it -- we should have vector types to begin with. We've had them in Fortran for over 20 years, though not necessarily in all compilers as you point out (I remember using a nice SIMD-aware commercial compiler back in 2001). Today, you can use Julia as a modern replacement of Fortran with a free compiler, though you may need to give the @simd hint in some cases.

I guess my physics background shows here. When we manipulate vectors in physics, we generally don't think of looping over all components sequentially; the components are a matter of representation, while the physical vector concept is independent of the coordinate system. Vectors also come with certain assumptions of independent operations per component.

Your post is also a good reminder to the folks who laud C's ability to work at the low level; in my impression, C was designed to act like a very simple processor, so as real CPUs become more complex, the low-level idea gets ugly with backward constructs like loop vectorization. To effectively deal with SIMD etc. you need a higher-level perspective of vectors/matrices, as paradoxical as that may seem.

Similar issues apply to multiprocessor systems, which have also been used in the scientific/HPC field for decades. So it's funny how it suddenly becomes completely new and hard to program for, when the same tech is sold to the general public in the form of multi"core" systems.

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:Indeed. C++ is a better C

[TheRaven64]

C++ has improved a lot, but there's still one place where it lags behind something like Lisp: you have to decide between compile-time and run-time specialisation very early. Constexpr functions were a big step in the right direction here, letting you move between compile-time and run-time computation without shifting syntax, but there's still no equivalent for data. If you want to do compile-time specialisation, you use templates, if you want to do run-time specialisation then you use fields. If you picked one and now want to move to the other, then it's very difficult to refactor, and if you want either compile-time or run-time specialisation in the same object for different uses then it gets clunky very quickly.

Re:Indeed. C++ is a better C

[jcr]

C++ is an amazing achievement.

You really need to get out more.

C++ is a steaming pile of needless complexity. I blame Stroustrup for his inability to say no whenever anyone came up with yet another feature to toss onto the dungheap.

The best thing about C++ is that you don't have to use all of it.

-jcr

Hasn't Ada fixed all of this decades ago?

[butzwonker]

What I find kind of annoying is that Ada fixed all these flaws decades ago with Ada 95, now it is at Ada 2012 and still gets no love, just because it's a bit more verbose than C if you use it correctly. (Though not necessarily more verbose than C++.) Sure it has some flaws, e.g. concerning aliases and their scoping rules, but these are mostly inconveniences and some of them have been fixed in Ada 2012. But it doesn't stop there, the same story can be said about dynamic languages. Take fancy new dynamic language X and you can be fairly certain that CommonLisp solved all the problems of the new language already in the 80s.

Maybe developers are in the end less rational than they think? It seems to me that a language must have serious flaws, lots of incoherent shortcuts and tricks, or at least a cryptic syntax to become really successful.

If you don't know where to start...

[Anonymous Coward]

... then how are you not clueless?

  Right now ESR is way ahead of you by having some actual thoughts to share, no matter how wrong they may turn out to be. You're nowhere near that. So you go on, pick any thing, start there.
  Here, let me help you: Me, I think that ideology makes for poor abstracting in programs, so rust is out. Incidentally that "community" is full of people who are so full of it they "can't even". (Which is one reason why ESR would be wrong picking rust as a successor to C: rust people "can't even", C people very much just do.) Now you pick anything else, maybe the next thing you can think of right off the bat, and enlighten us with your insights.

ESR is incompetent

[loufoque]

I remember I interacted with him back when he started the irker project.

That pretty trivial piece of software, written in Python, was riddled with bugs, and no amount of bug reporting and discussing with him the design mistakes got anything fixed for a whole week, despite him actively trying.
I rewrote the whole thing in C++ in two days and it always worked robustly from the get go.

Re:This seems to reinforce how clueless he is

[e70838]

I have studied deeply C++98. I try to avoid C++ and favor Java each time I can. I am programming since 1994 and I agree with every single word ESR said. I do not know if rust or go are the future. I think we can do better and that there are a lot of insight to get from Ada (and ravenscar).

Re:This seems to reinforce how clueless he is

[Anonymous Coward]

He seems to think C is in need of replacement. It is not. Memory management is not hard - and pointers is not a problem. Well, perhaps some lesser programmers have problems with those - nice that there are other languages for them then.

C++? Nice to have if you want object-orientation built-in. The language may have some flaws - but it is always best to not use each and every feature of some language anyway.

Java? It is a pain. And I am not referring to garbage collection pauses. If you choose Java, it is because you buy into garbage collection. I have come up against so many other limitations just using java to teach programming:
* What, I can't spend more than 2GB? Oh, maybe it is possible, but I need to jump through hoops for that? C/C++ gives me an 8GB array if I declare it. Java won't give me that amount of memory - neither in a single allocation nor in smaller chunks.
* Slow file i/o. Try writing a simple 'file copy' in java, and copy 50GB. Compare to 'cp'. Java has improved lately, but you must be very careful selecting classes/methods.
* Slow string handling. Parsing 100MB of text is slower than reading it in from disk, or even downloading it over the net. Unless you write it all yourself. So much for supplied methods.
* Lack of types. Everything is signed except 'character' which is 16 bit unsigned. Makes data compression & crypto unnecessarily kludgey.
* Lack of io capabilities. Try writing an array of "long" to a file - can you do it without an iterating loop & slow i/o? C can fwrite() any chunk of memory.

Construction metaphore

[DrYak]

And good frameworks help with that. When I build a house, I don't want a craftsman who takes time to learn how to use an adze so he can plane down lumber to the correct size for the job; I want a builder who knows he can get lumber of the correct dimensions right at the store.

On the other hand, when all you want to build is a garden shed, you can do it yourself in a quick week-end afternoon project by quickly nailing a few planks together. You definitely don't want a several month-long adventure involving half a dozen sub-contractors (and each further down, their own individual group of a dozen of sub-contractors), plus hiring a few special planification manager (because sub-contracors D and Y each out-source their screw to a different sub-sub-contractor. Incompatiubles) which will all require two hectars of work space around your shed. And somehow the garden shed need to be connected to an industrial triphase 380V power connector in order to be able to function.

Some time, over reliance on frameworks and helpers means that some very simple projects that would be handled by a few dozens of C or C++ lines of code (perhaps a couple of hundreds top), suddenly need to pull more than 20 MiBs of libraries in the package and are dependent on 200 different github repositories (hoping that they'll not blocked on the dev's whim - see Node.js and string alignement). And you need to use special command line settings to tell the VM to allocate 2 GiB of memory for the process.

Re:Provided you have infinite hardware resources..

[CptLoRes]

But what happens when everybody buys lumber at the store? There still must be somebody that make sure the lumber is the right size and quality for your project. This problem is exactly why we today need giga range cpu's and ram just to watch a web page. Nobody knows how to deal with the details any longer, and so they end up building a new house every time there is a new problem.

Re:This seems to reinforce how clueless he is

[lucasnate1]

The C standard doesn't prevent anyone from implementing a calling convention where there's a separate stack for parameters and return addresses. That alone would solve many security problems.

Re:Provided you have infinite hardware resources..

[Ambassador Kosh]

For HPC (high performance computing) I don't see C++ going anywhere. For HPC the only viable languages I see are C, C++ and Fortran since they have the best optimizing compilers.

Mostly I use python for command and control with a simulator written in C++ and this seems to be a pretty common setup for HPC applications.Command and control often has a lot of code but is 1% of the compute time so write it in a high level language and then do the simulator is something that is FAST.

Re:Provided you have infinite hardware resources..

[coofercat]

A colleague and I were joking around one day, when a hardcore-dev (with a lot less humour, and chronic flatulence, as I remember) overheard us. He maintained that super-terse code is easier to read than the alternative. Since we were just messing about, we both just let him say his peace and then stated that the One True Language was of course Turbo Pascal 6 (which sort of ended the conversation).

My take on it is that the terse syntax does make sense (more quickly) to someone who knows the syntax really well. If you don't know it quite as well, then the long-form is better because as OP says "the sentence would look wrong". Also, actual words are 'googleable' where as it's hard to lookup the meaning of "~->" or whatever. Thus, the long-form plays to more average programmers.

The question then becomes... who should a language be for? For the super-expert, or for the midrange programmer, or possibly even the junior? IMHO, midrange is a good place to aim at because that's where the majority are, and if they're using your language then you'd want them to be able to do so reasonably easily and safely. That way, of all the billions of opcodes executed around the world as a result of your language, the majority of them will be reasonably safe and sensible.

Go is a sign that the old beliefs are breaking

[snadrus]

GC was hacked-on for decades to no avail (in bringing it low-level).But now here it works well (very fast, concurrent).
What changed? The language spec was made very simple.

Compiling was a very tricky, slow business. Now here it's fast and relatively simple.
What changed? A simpler language. Smart people who know which options to take away.

Only painfully low-level languages could work with raw memory pointers. Now we have that in 2 friendly, "default-safe" languages.
What changed? Realization a lot of power comes from low-level operations.

So C & it's layered C++ will break as safer variants with the same power begin to exist.

High level languages depended on dozens of C libraries and libc. Go needs none of those.
What changed? A realization this is important.

A fork of Go now runs without a kernel on bare-metal ARM. That's the right space to grow into a kernel-module-capable language. Languages aren't fast or slow, their implementations are. Go's ease of portage suggests it could show up in the kernel.