Slashdot Mirror
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.
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.
There's enough business logic programmed in C++ and Java to keep both languages around until my kids retire and they're not yet in the workforce. Rust and Go, yeah doubt there's a single company of any size running their business processes on either.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
The higher the level of abstraction in your language, the higher the overhead it will create. Now, it needn't be so absolutely stupidly overengineered as .net is, but still the metric fits, the more safeguards and handrails your language comes with, the higher the overhead it incurs to have them. This is admittedly not really a huge problem in today's working environment because our computer speeds are far greater than our needs.
Still, somehow it feels silly that I need increasingly more powerful computers just to run the same kind of program, only because programmers can't be assed to learn their trade and instead rely on ridiculously overblown frameworks that is the equivalent of delivering a pack of soda with a semi because you have to bring a soda factory along with the workforce since the framework doesn't know how to deliver a single soda.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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.
Irony: Agile development has too much intertia to be abandoned now.
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.
I am TheRaven on Soylent News
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.
Anything that allows us to reduce errors, increase functional complexity, reduce development time, improve readability and maintainability, and/or make it easier to code for a greater amount of people, is progress in my book. Working at a higher abstraction level achieves some or all of those goals.
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. The skills to build instead of buy are useful in many trades (both building and programming), but they are expensive and a possible source of additional errors. Frameworks are often a good answer to that... as long as the developer understands the nature of the framework, its limitations, the licensing model, its viability, and thus can assess the consequences of using it.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
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.
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.
It's not always so clear cut. What you say is definitely true for naive compilers, but higher-level abstraction also often mean more information for the compiler and more freedom for the compiler. These can translate to better optimisations. To give a trivial example, languages like Java provide an abstraction that looks like a C struct, but don't require that the memory layout be visible to the programmer. Imagine that you create a struct-like Java object with RGB values to represent a colour and you do the same in C. Now you put them in an array and try to do some processing on them. The C version is constrained to lay out the objects as three fields with no padding (this is visible in the language with sizeof and will break ABIs if it dynamically changes). The Java version, in contrast, is allowed to put an unused padding field at the end of the struct. Why does that matter? If you want to vectorise the loop, then being able to guarantee 4-element alignment for every object in the array is a huge win. This is a legal transform for a Java compiler, but not a legal transform for a C compiler unless it can prove that no pointers to the array escape (and a few other constraints).
The big advantage of C was that a fairly simple compiler for a simple architecture could get very good performance. The disadvantage for C is that compilers quickly hit diminishing returns and the abstract machine makes a number of desirable optimisations unsound.
For example, if your language has a first-class notion of immutability, then this gives the compiler the opportunity to elide copies or add copies if they make sense for NUMA systems, and gives the compiler a lot more freedom with regard to reordering or eliding loads. Similarly, if your source language has higher-level notions of sharing then this means that you can avoid a lot of defensive memory barriers that you'd need for correct C/C++ code. If your language has stricter guarantees on aliasing, then a whole lot of optimisations suddenly become easier.
Any compiler optimisation is a mixture of two things: an analysis and a transformation. The analysis must be able to tell you if the preconditions for the transform are met. The more information you can give to the compiler, the more often the analysis can prove that the preconditions hold and enable the transform.
I am TheRaven on Soylent News
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.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
The higher the level of abstraction in your language, the higher the overhead it will create.
This is exactly why C++ remains popular among those who create large, complex, high-performance applications. C++ is well known for using zero-cost abstractions. That means you get the performance of low-level C code, but can design much safer interfaces and type safety in your code which allow the compiler, not a runtime, to validate that the code is correct and safe.
For certain types of applications, it's an effective compromise between the pragmatism of retaining backwards compatibility with decades-old ecosystems, while at the same time providing better safety and abstractions than C.
Irony: Agile development has too much intertia to be abandoned now.
He seems to think C is in need of replacement. It is not.
Some of us care about security, and C suffers from a lack of strings or arrays*, making buffer overflows a way of life. This needs to be remedied, and "just don't do that" isn't a remedy.
-jcr
* C has pointers and some syntactic camouflage that makes them appear to be strings or arrays. Don't be suckered.
The only title of honor that a tyrant can grant is "Enemy of the State."
With some extra spaces, and the whole thing changed to an expression (which is how ?: is supposed to be used) it's a lot easier to read.
b = (a != 1) ? !b : 0
The advantage of the ternary operator is that you only need the LHS part once, which helps if it's a more complex variable.
How do I write drivers and firmware in Go? I think C is going to be around for awhile.
We'll make great pets
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.
Escher was the first MC and Giger invented the HR department.
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.
Avantgarde Hebrew science fiction
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.
Computer modeling for biotech drug manufacturing is HARD!
People who do electrical engineering learn to read and understand the funky symbols they use in electricity. We don't expect them to write out everything in plain English. It's the same with programming. Your Pascal-y pseudo-code took how much more space and time to convey no extra information? Your pseudo-code actually took longer for me to parse and understand than the C version.