Should C Programmers Learn C++, Go or Rust? (2018)
ds9a.nl
ds9a.nl
None of that is true. The biggest memory safety flaws that have caused the most damage have been, more often than not, written by the best C and C++ programmers. That's because the best programmers are the ones who write the critical C and C++ code--Chromium, Firefox, WebKit, the Linux kernel, nginx, libpng, libjpeg, libc, etc. "Bad programmers" (whatever that means) can't, and don't, usefully contribute to projects like WebKit to begin with.
The problem is with the tool. Though it's an inconvenient fact to accept, humans have shown themselves incapable of writing safe C and C++ code at scale using standard software development practices (i.e. not spending 10x on verification). That C and C++ are due to be replaced shouldn't really be controversial--it's natural to expect that we know how to design languages better now than we did in 1978.
Google and Mozilla might never get out from under their burden of enforced bad coding habits. It is a mistake to attribute to a language the flaws of one's corporate culture.
C++ is not at all under threat of being replaced. The number of C++ programmers is increasing at a much greater rate than of Rust programmers, and the language is evolving quite rapidly after its stagnation in the '00s. If you learned C++ before you could use C++11, you will be surprised at how much more fun C++ is now. Coding C++20 will be even more fun.
That's just not true. Both organizations use "modern C++" everywhere. The new C++ proposals tend to come from large companies such as Google, after all.
People tend to assume that every new release of C++ will automatically solve all the problems with the previous releases until proven otherwise. This has always mystified me. Nobody has demonstrated that any new version of C++ has been able to stem the flood of memory safety problems.
It's interesting that few people can actually articulate why modern C++ supposedly solves the memory safety issues, other than just mentioning smart pointers. Smart pointers actually do very little--shared_ptr can bump reference counts sometimes and that's about it--and what little benefit comes from smart pointers is generally outweighed by all the new ways to get use-after-free in modern C++. Free happens invisibly in subtle places in modern C++, while in C free happens explicitly when you write "free()", which tends to be safer. In my opinion, modern C++ is significantly less safe than classic C++, which is in turn significantly less safe than C.
I don't know why you carry on about smart pointers. I find I use unique_ptr here and there (shared_ptr, practically never), and never, ever in any interface. Instead, modern C++ code traffics in value types, and relies on destructors, almost always from a library or compiler-generated, for cleanup. Use-after-free never happens because anything freed was only ever referenced from within a value-typed object that no longer exists.
The reason that, in modern C++, memory safety issues fade into insignificance is that we have access to libraries that are fully as fast as we could ever code in-line, optimized as only code that is used in many places can afford to be, that encode logic correctly, once, that can be used everywhere without compromise.
Rust does not yet have the facilities to capture as much semantics in libraries. Anything Rust can't capture in a library has to be coded in place, with all the opportunities for mistakes that brings.
So, Rust is good at safing low-level memory fiddling that we just don't do much of, anymore, in C++. Meanwhile, we avoid myriad errors that come from relying on necessarily leaky abstractions.
Rust Rayon is a huge difference from anything available from C++, and it can't be solved in C++ without adding borrow checker to the C++ language (which wouldn't be a bad thing to do in my opinion, it would help modernizing old code bases).
Likewise, multi-threaded race problems.
If anything, low-level memory fiddling is becoming more common and more widespread. Vulkan and D3D12 get lower level than ever before in what they expose. Webassembly brings pointers back to webpages like it's the 1990s and we're rocking ActiveX. I fear I'm soon going to have to start running address sanitizer for webpages.
People tell me modern C++ solves this problem, but supposed examples of it invariably underwhelm me. I suspect people claiming such just have lower standards. MIRSA C can help. NASA-level piles of documentation and rules and restraint can help. Enough unit tests that you start to catch more compiler bugs than library bugs can help. Drowning the end user in the false positives produced by modern C++ static analysis tools can help. Thorough fuzz testing can help. But these are ancient techniques, not modern. Combine all that and more and, yeah, you can actually get kinda close to practicing safe C++. But this level of care is rarely practiced.
No, the real problem I think is very few people are capable of the skill, patience, and fortitude to write strictly correct C++, and they rarely have the time to. And absolutely none of them were born with that power. Fresh blood will learn from their mistakes, and we will pay for those mistakes in sweat, tears, missed milestones, and CVEs.
I'd love to be proven wrong. C++ pays my bills and has a great ecosystem in a lot of ways - I'd love if it were salvagable. Meanwhile, the last C++17 upgrade attempt I saw failed when we decided we were unwilling to maintain a fork of the standard library to fix compilation issues in the vendor's implementation for one of our platforms.
Are std::vector and std::string "value types"?
> Use-after-free never happens
Yes, it does.
> The reason that, in modern C++, memory safety issues fade into insignificance
No, they don't.
But you knew they came from C++98. Maybe you meant to ask if I still use them? I do. But I don't store references to their elements.
This is a straw man. Nobody in the C++ community action like the next release is a silver bullet. On the other hand, people in glass houses...
Smart pointers help (but do not solve) memory issues by tying together access and resource destruction. If you access a resource through an object, and the resource don't go away until the object does, it makes it harder to access the resource after it's gone. Not impossible since you can do various things like grab a raw pointer/reference to the smart pointer and then call reset. In practice though, this doesn't occur that often; Murphy is a bigger problem than Machiavelli.
You're entitled to your opinion but it goes directly against my experience, and most industry experience. Most C and old C++ codebases, memory management over time just becomes a tangled mess of ad hoc delete calls. With smart pointers this just hasn't happened and in practice spent tiny fractions of my time still dealing with memory related issues. A language with e.g. real reflection would be a way bigger boost to my productivity than improved memory management.
The security problems of C and C++ programs are caused by the fact that it takes effort to write safe code in those languages and most programmers/companies can live just fine with the safety they can reach with less effort. Bugs are opened, the code is patched and the world goes on.
And because those people don't obsess over memory safety, they won't switch to Rust either, unless something else happens to force them to. E.g: great job opportunities, official toolchain in Rust, etc.
Maybe C and C++ are due to be replaced, but hopefully not by Rust, because at least back in 78 they could create a language that's at least moderately fun to use.
"People who obsess over memory safety" are in fact not writing in C and C++ these days.
> The security problems of C and C++ programs are caused by the fact that it takes effort to write safe code in those languages and most programmers/companies can live just fine with the safety they can reach with less effort.
No, this is not true, unless you define "effort" as "10x normal development costs and time", which does not make economic sense for mainstream software.
Regarding your second point: Firefox has vulnerabilities patched in almost every version (although the last one was a certificate screw-up). Are people abandoning Firefox because of that? Are you having trouble attracting talent, because it's written in C++? Are people switching to Chrome en masse because it has better security?
Even a project with middling memory safety like Firefox is able to survive just fine in a space where security's aaalways argued about. It's perversely lost market share because of Google's marketing and its poor performance. So one doesn't need to invest 10x development costs and time, probably not even 2x.
I feel like Rust has expanded pie for c-level performance languages. For system languages. I'm not comfortable writing C or C++ - if I miss something, it means UB. I am comfortable writing Rust - it generally yells at me if I were to trigger UB (modulo unsafe, which I stay away from).
Edit: Though I have to admit, my point doesn't apply to the article. He's only talking to 'C' programmers in the article.
With Rust thanks to the borrow checker and all the help from the compiler you won’t need that wizard in your team. That means less stress thanks to the compiler and less management and you can have a team with a lot of junior devs without having the necessity to have anybody to be senior to oversee the code and you can still be confident to ship code to production.
- D is a safer, cleaner, more convenient version of C++. It has a Rust-like build system/package manager (dub), a sane module system, Rust-like unit tests available anywhere, C++-like compile-time expressions and functions, C++-like generics, and contract-style programming (which C++ is also about to get) for safer code. Oh, and the D compiler is known to be fast, unlike C++ and Rust.
- OCaml is a pragmatic functional programming language focusing on a sound static type system with strong modules support, rather than on total purity. It too has a fast compiler and targets JS as well as native.
In my current job I am now using C++14/17 (not my choice). I'm starting to like auto, but not much else. The "smart" pointers and "move" are hard for me to reason about still. I'd have an easier time reasoning about raw pointers and references, mainly because that's all I had in my early C++ days and C days (of course). I think things like asan and ubsan are far more helpful even with plain C than features like smart pointers.
I've tried Rust. The author of TFA linked to another article explaining that rust tricks you because it looks like languages you have used before, but it's really not like them. That made me feel better about my experience. I found it to be very frustrating. I'll have to try it again with a different mindset.
I haven't tried go, but I don't feel like it's a viable embedded programming language because of it's garbage collector. At least not for tightly contrained embedded systems. I'm honestly not sure rust is going to work for those types of systems either. Sometimes you just have to poke bits into memory and I'm not sure how a super safe language will deal with that better than C.
I agree. Smart pointers are not effective safety features. They mostly add new ways to get use-after-free. (shared_ptr helps a bit by automatically bumping reference counts, but shared_ptr is often discouraged in modern C++, and there are lots of ways to get around this, such as "shared_ptr&".)
> I'm honestly not sure rust is going to work for those types of systems either. Sometimes you just have to poke bits into memory and I'm not sure how a super safe language will deal with that better than C.
Read the "Writing an OS in Rust" series. Even in the kernel, you can have a relatively small trusted computing base and then most of the rest of the code can be safe.
When I try to see my self in the shoes of a primary C dev, I wouldn't see Go as a concurrent to C, but more as a less annoying scripting language. Every time when I switch from a "typed" to an "untyped" language, I do need a longer time to "feel at home" again. Therefore I think Go could be good language for a C dev for small tasks on the site, like creating small cli tools for the buildchain or generally inhouse, things like that what one normally tends to look at python for. Go makes it easy to create a good cli interface, easy to document the format of a config file and writing a test. Deployment is also easy thanks to that is just a static blob that comes with everything that it needs. So no worrying about if the right interpreter is installed on that dev server, just copy it over with scp and it works.
C++ is complex to parse. Clang and Gcc use back-tracking to parse C++ and there can be long compilation times.
Tiobe language rankings for May 2019:
Rust is ranked 34th at 0.335% below Lisp and Prolog
Go is ranked 19th at 1.114%.
In complexity and size, Go language is closer to C programming language than either Rust or C++. [Rust and C++ are much larger languages than Go.]
Lastly, Rust does not appear to have a standard BNF grammar specification and I counted around 33 FIXME unspecified sections in the reference document for Rust. I haven't even discussed the number of unstable features in Rust. in the Ref
The future will identify other features, in other languages, that Rust can never have, for the same reasons. Rust is very quickly accumulating unfortunate accidents that will make is seem less shiny as it matures. That is just a natural progression.
Will Rust ever be mainstream? It is still possible. In five years it either will be, or will be fading and something else capturing attention it commanded. Only time can tell.
Are you saying that Rust is rusting? :)
I have worked with some Go, and found it reasonably practical, if a little boring and verbose. Not necessarily a bad thing if you're writing a big program with a large team with widely-varying capabilities. But it's hard to get the enthusiasm to write more Go recreationally. The standard library is remarkably thorough, though I'm a little disappointed at how bare-bones dependency management and control is.
I find I enjoy Rust rather well. I don't consider myself to be particularly smart, but I haven't run into much trouble fighting the Rust borrow checker. It does force you to think more about exactly what should own what at any particular time, and exactly what to do in any particular error situation, which is probably a good thing. Sometimes you have to throw some clones and random &s around to get things working, but I've always been able to sort it out so far. And it's the first language in this space with a dependency management system that actually compares to dynamic languages like Ruby.
> I'm a little disappointed at how bare-bones dependency management and control is.
Is that referring to Go modules, or to the situation before it? I just started using Go modules in my active projects, and I find that it matches your overall characterization of Go: reasonably practical, a little boring.
Go and C seem to have a large number of available software tools.
Based on the "size" of the reference documentation alone, C and Go appear to be the simplest to learn for beginners.
A beginner coming from a C background might choose to learn the "Go" language, of the 3 available choices: C++, Rust, and Go.
Other than it's declaration syntax, Go appears to have been designed to be the most familiar to a C programmer.
C++ is very large and complex, just look at the size of the reference documentation. The 4th edition of "The C++ Programming Language" doesn't even have an "Appendix A: Grammar" anymore.
Rust doesn't appear yet to be stable enough to even specify a BNF for it's grammar.
Of course, there are other programming languages out there that maybe are even better for a C programmer to learn, but we were not asked for our opinion of other PLs.
To first order, it doesn't matter which you pick, because we will all be better off than if you continue producing C code.
For production code, it is probably too early to switch to Rust, most places. Give it five years. But it won't be a mistake, then, to have five years' experience with it.
Rust and C++ will require more learning and adaptation than Go. Don't be fooled by C++'s apparent similarity to C: to get the benefits, you need to code the modern C++ way to reduce the window for low-level mistakes. Rust makes it hard to code the C way, so needs less coding discipline, but the Rust way takes more getting used to.
Both Rust and C++ can be substantially faster than C, for different reasons. C++ is better at capturing semantics in libraries. Rust knows more about what code is allowed to do, and can optimize accordingly.
Go is probably easier to switch to from C. There is not as much to learn. It's garbage-collected, so there are places it won't go, but most people won't need to go to those places.
It is never a mistake to know more than one language. In a sense, you don't have to choose one, you only have to choose what to learn first.
Generally, I think the performance differences between C, C++, and Rust are so minute as to be not really worth worrying about. In practice, small differences in the way you write the code makes way more of a difference than anything in the languages. This is not surprising when you consider that the three languages literally share the same compiler backend in many cases (LLVM), and core operations in each language generally map down to the same IR instructions.
30% may be no great shakes vs the 1000%+ available switching from Python, but in this post-Moore's-Law world, it is nothing to sneeze at.
Which is a unfortunately a thing in C
Another is the ability to pass a lambda to library function, and compiled directly into it, where C would need to pass a pointer-to-function to be called indirectly.
Both contribute to the showcase sorting example, which is used frequently because it had proven to be understandable, not because it is unique.
People have been saying this for decades about various languages and C is still the standard for performance except for a few specific cases. How many more decades until we can consider this "sufficiently smart compiler" a myth?
Fortran used to be the language for what we now call HPC. C was too slow. C++ is used now. This did not happen because Fortran got slower. Instead, C++ got faster.
The reasons are interesting. It turns out that to get faster Fortran, your compiler vendor has to code optimizations in the compiler. But in C++ you can code them in a library, and not wait on the attention of a compiler developer.
Care to share some examples? I know there are a few specific ones like sorting but every benchmark I've ever seen has c coming out ahead in most tests, especially when c++ features are used.
> Fortran used to be the language for what we now call HPC
Again that was a fairly specific case usually only seen in scientific applications.
From your other post:
> It is not unusual for a C++ or Rust program to be 30% faster than the C program it replaces. The reasons are worth studying.
Citation needed, this is so far off from every benchmark I've ever seen it's laughable.
Then, use C++ features anywhere they make it faster.
If you knew C++ I could go into more detail, but if you knew C++ we would not need to have this conversation.
That is simply not true and easily demonstrably false: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
> Compile the C program with a C++ compiler, and they are exactly the same.
Why would I compile a C program with a C++ compiler? But in any case the above link both used gcc and shared most of the compiler backend.
> If you knew C++ I could go into more detail, but if you knew C++ we would not need to have this conversation.
Your assumptions is wrong on multiple levels, I know C++ (admittedly rusty though) and it is not self evident, the opposite in fact.
Your benchmarks demonstrate only that it is possible to write slow code in any language, even a fast one.
It would be easy enough to make the C programs equally slow, still proving nothing about either language.
> You would, if you were scrupulous, compile your C program with a C++ compiler to prove absolutely that C cannot be faster than C++
If my program compiles, which is a big if because c is not a subset of c++, all it would demonstrate is which compiler is better. A c program being compiled with a c++ compiler doesn't gain any type information, it can't make any assumptions that the C compiler couldn't.
> before going on to make the C++ version faster, using features that do not exist in C.
Which features? It's certainly not going to get faster by throwing in OO abstractions and virtual methods.
> Your benchmarks demonstrate only that it is possible to write slow code in any language, even a fast one.
Then show me some better ones, so far I've provided more examples supporting your point than you have.
If you compile any C program with a C++ compiler (possibly making trivial changes to account for gratuitous language divergence) you will find, for reasons you note yourself, that it runs at exactly the same speed. NOT, let me emphasize here because this seems to be difficult to process, ever slower than C. Therefore, (try to follow this) C is never faster than C++.
So, it is at best foolish to insist that C can ever be faster than C. The falsehood is trivially exposed.
If you think that C++ is about OO gook and virtual functions, an education awaits. But not here.
Enough with the faulty logic, where are the benchmarks proving it? I've still provided more evidence of your assertion than you have.
From there, maybe you could use C++ features to improve the speed (and then C++ is faster) or you could not (and then they have the same speed).
Pretty much every benchmark I've ever seen, I provided one further down but here's another one: https://thenewstack.io/which-programming-languages-use-the-l... . Yes benchmarks can have many pitfalls but when literally all of them show the same unsurprising result (that more abstraction means worse performance) I think it's safe to trust them. Have you got a citation that shows c++ generally outperforming c?
> Most of the most performance critical industries like game dev, high frequency trading, are primarily in C++, not C
And I'd be willing to bet that the more critical components look a lot more like c than c++, not "modern c++".
> Well written C++ tends to be more performant than C largely because there's just much less indirection in using templates than C equivalents (function pointers, void*, etc)
Yes that's one advantage, it's one of the few specific cases where c++ performs better that I outlined. Even then _Generic_ in C can often give you a way to do the same (in an uglier way).