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.
Rust and Go, yeah doubt there's a single company of any size running their business processes on either.
Regarding Go. Ever heard about Google? They are running a lot of it...
Docker is written in Go. Docker is probably single biggest thing happening in devops area in few last years and many, many companies are deploying it in production. And docker is exactly the thing you are 'running you business process on' ;)
I dont think ac has a grasp on how many times google has pulled that trick before xD
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).
I am TheRaven on Soylent News
GCC can vectorize pretty well.
You may have to give it some hints and be careful how you code your loops but it works. See this article. https://locklessinc.com/articles/vectorize/
That was using GCC 4 some years ago. I have not checked but I'd wager it's even better now.
Clang/LLVM also does a good job of vectorization.
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.
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.
ESR has been called ESR on Slashdot and elsewhere for decades; he even answered questions here on /. in a story titled "ESR Answers Your Questions". This is about using a nickname, not an abbreviation.
The following is just a small selection from the past:
Computer usernames were the nicknames that geeks of yon' generations used for each other. Especially if you used early chat programs on the old timesharing systems:
ken - Ken Thompson
dmr- Dennis Ritchie
bwk - Brian Kernighan
esr - Eric Raymond
Pimpl is solvable by creating an implementation class and and interface class that has a reference to that class, and if you are crying about memory safety starting with C++ 11 there are smart pointers.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
ESR is adopted by Eric himself, in his e-mail (esr@snark.thyrsus.com) and his personal home page (http://www.catb.org/~esr/).
If you are doing things in which you need to be sure about security and/or safety you should be using static and dynamic tests and checks, which would find most of those issues with pointers and arrays. You should do those things even with a managed language.
Also, I would much prefer a language that allows me low level things (there is no reason you cannot implement a Pascal-style string in C, for instance) instead of forcing some restricted choice of operations decided by the language or library committees.
As for garbage collection - if you are really into security or safety, the most robust approach is to have no dynamic memory allocation at all. But when dynamic memory allocation is required, it really would be nice if deterministic (in both runtime and time-of-run) garbage collectors were available.
"There are a dozen opinions on a matter until you know the truth. Then there is only one." - CS Lewis (paraprhase)
Rust and Go, yeah doubt there's a single company of any size running their business processes on either.
You didn't even check before posting. Go is used at many companies, and even the younger Rust makes some money: https://www.rust-lang.org/en-U...
I work for a FTSE250 UK company and we're running lots of Go in production and the company now depends upon it for important business processes. We continue to see an aggressive growth the use of Go in most areas of IT in our company.
We also have one specific bit of code in Rust also running in production because Go is not appropriate for it, but we're unlikely to increase the use of rust much more.
My previous company (a major UK based international publisher) is in a similar position since I introduced Go there a few years back.
So, that's two companies of reasonable size running their business processes on Go.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
A C compiler may add padding, but its ability to do so is constrained (or mandated) by the platform ABI. The layout of a struct is exposed directly in the language because you can ask for sizeof() the struct (which, if you subtract the size of all of the fields will tell you the total padding) and you cast a pointer to a field and a pointer to the struct to char*, subtract one from the other, and get the offset of each field. This means that it is effectively impossible for a C compiler to add padding to make optimisations easier (the only case in which they will reliably do it is for on-stack structs that are not address-taken).
I am TheRaven on Soylent News
That's an awfully content-free posting to get (4, Interesting), given that it boils down to "I don't like C++ because it's complex". If you read Stroustrup's Design and Evolution book, you can actually find out why Stroustrup added what he did and rejected what he did.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
I can understand why you'd prefer Java. C++11 and the following standards make it a much different and easier-to-use language.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
That is not the opinion of anybody I've seen who actually uses the language. The changes make C++ a much better language.
Some of the new library features were adapted from Boost, but you're welcome to try writing lambdas and using move semantics (and std::unique_ptr) in C++98. "auto" was completely repurposed, since as far as anyone could tell nobody actually used it, and you can use it to write templates you couldn't in C++98. Plenty of other changes.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes