Why Modern C++ Still Isn't As Safe As Memory-Safe Languages Like Rust and Swift (alexgaynor.net) 463
Alex Gaynor is a software engineer at Mozilla working on Firefox, after previously serving as a director of both the Python Software Foundation and the Django Software Foundation.
In a new blog post today, he argues that memory unsafe languages, "principally C and C++," induce an exceptional number of security vulnerabilities, and that the industry needs to migrate to memory-safe languages like Rust and Swift by default. One of the responses I frequently receive is that the problem isn't C and C++ themselves, developers are simply holding them wrong. In particular, I often receive defenses of C++ of the form, "C++ is safe if you don't use any of the functionality inherited from C" or similarly that if you use modern C++ types and idioms you will be immune from the memory corruption vulnerabilities that plague other projects. I would like to credit C++'s smart pointer types, because they do significantly help. Unfortunately, my experience working on large C++ projects which use modern idioms is that these are not nearly sufficient to stop the flood of vulnerabilities...
Modern C++ idioms introduce many changes which have the potential to improve security: smart pointers better express expected lifetimes, std::span ensures you always have a correct length handy, std::variant provides a safer abstraction for unions. However modern C++ also introduces some incredible new sources of vulnerabilities: lambda capture use-after-free, uninitialized-value optionals, and un-bounds-checked span.
My professional experience writing relatively modern C++, and auditing Rust code (including Rust code that makes significant use of unsafe) is that the safety of modern C++ is simply no match for memory safe by default languages like Rust and Swift (or Python and JavaScript, though I find it rare in life to have a program that makes sense to write in either Python or C++). There are significant challenges to migrating existing, large, C and C++ codebases to a different language -- no one can deny this. Nonetheless, the question simply must be how we can accomplish it, rather than if we should try.
The post highlights what he describes as "completely modern C++ idioms which produce vulnerabilities" -- including an example of dangling pointers "despite our meticulous use of smart pointers throughout..."
"Even with the most modern C++ idioms available, the evidence is clear that, at scale, it's simply not possible to hold C++ right."
In a new blog post today, he argues that memory unsafe languages, "principally C and C++," induce an exceptional number of security vulnerabilities, and that the industry needs to migrate to memory-safe languages like Rust and Swift by default. One of the responses I frequently receive is that the problem isn't C and C++ themselves, developers are simply holding them wrong. In particular, I often receive defenses of C++ of the form, "C++ is safe if you don't use any of the functionality inherited from C" or similarly that if you use modern C++ types and idioms you will be immune from the memory corruption vulnerabilities that plague other projects. I would like to credit C++'s smart pointer types, because they do significantly help. Unfortunately, my experience working on large C++ projects which use modern idioms is that these are not nearly sufficient to stop the flood of vulnerabilities...
Modern C++ idioms introduce many changes which have the potential to improve security: smart pointers better express expected lifetimes, std::span ensures you always have a correct length handy, std::variant provides a safer abstraction for unions. However modern C++ also introduces some incredible new sources of vulnerabilities: lambda capture use-after-free, uninitialized-value optionals, and un-bounds-checked span.
My professional experience writing relatively modern C++, and auditing Rust code (including Rust code that makes significant use of unsafe) is that the safety of modern C++ is simply no match for memory safe by default languages like Rust and Swift (or Python and JavaScript, though I find it rare in life to have a program that makes sense to write in either Python or C++). There are significant challenges to migrating existing, large, C and C++ codebases to a different language -- no one can deny this. Nonetheless, the question simply must be how we can accomplish it, rather than if we should try.
The post highlights what he describes as "completely modern C++ idioms which produce vulnerabilities" -- including an example of dangling pointers "despite our meticulous use of smart pointers throughout..."
"Even with the most modern C++ idioms available, the evidence is clear that, at scale, it's simply not possible to hold C++ right."
Rust band wagon garbage (Score:5, Insightful)
If these rust fanboys would actually work on making the language/runtime PORTABLE across operating systems and architectures, then maybe it could someday replace C/C++.
I'm tired of hearing how great Rust is. it's not. It doesn't run on most *BSD operating systems. The ones that do have it have bugs/portability issues and upstream sucks. The language was written for win/mac/linux on x86 and ARM. Nothing else was seriously considered when it was designed.
You can't replace C with a language that runs on one compiler, with only a few CPU architectures and operating systems.
Re: Rust band wagon garbage (Score:5, Insightful)
Bingo.
C will never be replaced, as it is the ONLY portable language to all CPU types, platforms and the only language libraries can be used as.
As much as I hate the overuse of OOP for OOP-sakes, C++ and OBJC are still the only OOP languages that come with operating systems, but the C++ runtimes are often not as portable with each other due to compiler ABI bullshit.
If Rust wants to get adopted:
1) compile rust programs to the C runtime without requiring a shared platform- specific library
2) Rebrand. Sorry, Rust is a terrible brand name. It makes people think the opposite of Swift.
3) Donâ(TM)t version it. The quickest way to destroy adopting of a new language is depreciation of API between versions. Create one API, and then never change it in favor of safer, better, faster bullshit.
People are abandoning Java and .NET tech because of this stupidity and C# has only persisted outside of Microsoftâ(TM)s control (eg Unity)
Re: Rust band wagon garbage (Score:3, Insightful)
C is inherently unsafe for obvious reasons. C++ is obviously unsafe when you use it like a dumbass. If you write in these languages you're basically making a handshake agreement with the future that you are competent. As disrespected as both are for different reasons, elegant code written in either is beautiful and defies any semblance of scorn.
As a programmer, and I mean to use the term in the most extreme way a computer scientist or electrical engineer would, a great C++ programs pulls you in and shines.
N
Re: (Score:2)
C++ is obviously unsafe when you use it like a dumbass.
The article makes the argument that C++ can't be used smartly. He has some interesting reasons. What do you think about them?
Re: (Score:2, Insightful)
The article makes the argument that C++ can't be used smartly. He has some interesting reasons. What do you think about them?
I think he's a dumbass.
C++ can be used smartly, it just needs you to educate yourself to not do dumbass things.
Re: Rust band wagon garbage (Score:5, Insightful)
The endless parade of CVEs due to memory unsafety in C/C++ software proves that "just be smarter" hasn't worked.
I know a lot of really great C++ programmers working in top organizations (Mozilla, Google, Facebook, Apple, etc). None of them claim to be able to consistently write safe C++ code. I don't either:
https://robert.ocallahan.org/2... [ocallahan.org]
The only people I see claiming to be able to consistently write safe C++ code are random commenters on Internet forums. I'd genuinely appreciate some references to high-profile programmers who've worked on large, widely deployed systems in C++, who vow they can consistently write safe C++ code.
Re: (Score:3)
I often hear phrases like "vulnerabilities in C/C++ software". Since we're talking about modern C++ here and not C, this discussion is only meaningful if we categorize those into C, pre-C++11, and "modern C++" when discussing said vulnerabilities. Those are all significantly different languages.
My guess is that the vast majority are going to be C code, not only because it's easiest to make memory-related mistakes in, but also because so much low-level system code is written in it (e.g. the entire Linux ke
Re: Rust band wagon garbage (Score:5, Insightful)
Treating "modern C++" as a separate language would be somewhat fair if we also separated out "modern C++" when talking about the popularity of C++, the projects using C++ and the number of people who "know C++". "Modern C++" is a much less popular language than "C++".
Talking about "modern C++" as a separate language also requires broad agreement on what "modern C++" actually is, and unfortunately no such agreement exists. For example a lot of people I see using that term seem to mean "C++14 and up", not C++11. And of course even more important than what's been added to "modern C++" is what has been deprecated. Are exceptions part of modern C++? Raw pointers? Some people even argue on this very comment thread that string_view and span should not be considered part of modern C++ because they're experimental!
The answers to these questions change over time too.
I think you're right that we don't yet have a ton of data to evaluate the safety of "late modern C++" in practice, but I think you should also acknowledge that the original article shows that at least there have been some significant backward steps.
Re: (Score:3)
> "Citation needed"
Lots of projects use pre-C++11 C++.
Re: Rust band wagon garbage (Score:3)
The problem is that there is no such thing as âmodernâ(TM) C++. You canâ(TM)t throw a compiler switch that ensures that you canâ(TM)t just cast everything to a (char *) and screw everybody. Until then C++ will always be just as insecure as the portable assembler itâ(TM)s derived from.
Re: (Score:3)
For example a mutex in C++ is not associated with the data it's protecting so it's easy to forget to lock it. A smart pointer won't care if you try to call it when it's been reset and contains a NULL. I recently had to fix code that created two
Re: Rust band wagon garbage (Score:3)
Google and Facebook are definitely not top organizations when it comes to software engineering, especially when it comes to C++.
Google in particular decided to dumb down their coding standards because it cannot trust its own employees to understand real C++ code, and are pushing for Java and other code-monkey-type languages to be used throughout the firm instead.
Re: (Score:3)
Has your code been studied by black hat hackers using fuzzing and all other tools at their disposal to find memory safety errors? Mine has. If yours has, reference please.
Re: Rust band wagon garbage (Score:4, Informative)
The article that spawned this comment thread has examples of how modern C++ features make it easy to make mistakes that produce dangling pointers. In 2019.
Re: (Score:3)
Also, your sanitizers are only as good as your test coverage. Have you run coverage-guided fuzzing? What is the branch coverage of your automated test suite?
Re: (Score:3)
The number of people capable of successfully using C/C++ in safe ways, while not zero, is far lower than those who think they can do so. This has lead to a lot of problems.
The number of people with the necessary chops available to maintain and update code written by that small group of ultra-capable types without introducing problems is far smaller than the number necessary to support such individuals output as they move on from project to project and job to job. This has lead to a lot of problems.
The numb
Re: (Score:2)
The main problem with C++ is that it is a vast every-changing language. It may take 10 years of practical experience
Re: Rust band wagon garbage (Score:5, Insightful)
Scott Meyer is an interesting example. He recently wrote http://scottmeyers.blogspot.co... [blogspot.com] :
> As you may know, I retired from active involvement in C++ at the end of 2015, and in the ensuing two and a half years, Iâ(TM)ve forgotten enough details of the language that I am no longer able to properly evaluate bug reports regarding the technical aspects of my books. C++ is a large, intricate language with features that interact in complex and subtle ways, and I no longer trust myself to keep all the relevant facts in mind.
Evaluating the correctness of his own C++ examples is too hard for Scott Meyer once he stopped using the language for a couple of years. And this isn't talking about new features he doesn't know about; it's about old code that should still work.
No doubt C++ fans will dismiss Scott Meyer as someone who never really understood C++.
> View objects (span/string_view) are unsafe. Yes, but only if used as return values,
His very first example does not involve return values.
> and only if you're not using static analysis, which you should be.
Which static analysis? Is it guaranteed to catch all these safety bugs? Do all projects agree on which analysis to use? If everyone should be using static analysis why isn't it part of the language?
> You can creation uninitialised memory with std::optional, IF, you go out of your way to do so! Well, you can format your hard-disk if you go out of your way to do so.
It's a lot harder to accidentally format your disk than to accidentally leave a variable uninitialized. How many times have you done the former and the latter?
What you're saying here is "people shouldn't make mistakes". Sure. The reality is that people do make mistakes and coping with that is important.
> The main problem with C++ is that it is a vast every-changing language. It may take 10 years of practical experience to understand the best ways to use particular features.
This is a damning indictment of C++.
Re: Rust band wagon garbage (Score:4, Insightful)
For Java, that's a non-issue because all fields are initialized by default.
For C or C++, I bet you have left a field of a struct uninitialized. Compilers rarely warn about that.
Re: Rust band wagon garbage (Score:5, Insightful)
Re: Rust band wagon garbage (Score:4, Insightful)
Back in the real world, every programmer makes mistakes. Even the most skilled programmer will write code that crashes, or races, or leaks, or does something dumb. Teams have developers at different levels of competence so the risk is higher again.
Rust takes the view that it can stop a lot of these problems even happening through the design of its language. The result is safer, more stable code.
Re: (Score:3, Insightful)
Deprecation is essential because language features and APIs inevitably have to evolve over time. Breaking backward compatibility DOES cause massive damage (see Python3) and indeed Rust is not doing that.
Re: Rust band wagon garbage (Score:4, Interesting)
Even C isn't that consistent when ported. For example it assumes a flat memory model, with no support for multiple memory buses or paging.
C doesn't assume a flat memory model. Have a read through the C11 Programming Standard and you'll notice that discussions of memory models are completely absent. You'll also notice that the rules around casting between pointer types appear quite complex. You'll notice that a null pointer is not simply defined as a pointer with address 0. You'll notice that function pointers and data pointers are not interchangeable - they don't even have to be the same size. You'll notice that pointer arithmetic and comparison are undefined unless the two pointers point at or into the same object. The C standard bends over backwards not to impose any kind of memory model on the implementation.
I don't know why you even bring up paging. The whole point of paging is to be able to allocate physical memory among many processes without those processes realising they don't have access to the full address space. Paging has been around for longer than C but no application programming language has "support" for it. That's the the whole point of it.
Alignment is another issue. Take ARM, for example. It does 32 bit word aligned accesses only. If you want less than 4 bytes you have to read 4 bytes and then shuffle bits around. So when you have a pointer to a byte things get hairy. The compiler has to generate a whole load of code to handle the two LSB.
That's completely incorrect. ARM can read a byte from any address with one instruction. The way it does it is to read the entire word containing the byte and then select the exact byte in the processor, but this is all transparent to even an assembly language program.
Again, many compilers try to hide this by aligning everything to 4 bytes by default, which is okay because C doesn't specify how structs and the like are to be packed... Except that a lot of code relies on them being packed a certain way, so you start getting into compiler extensions and a kinda of pseudo-standard based on what GCC does.
The C11 standard explicitly allows implementations to align and put padding in structs any way they like precisely to allow for alignment restrictions in the processor. If you write a program that relies on a particular packing format, it is not conforming to the C standard.
Re: (Score:3)
For Harvard architecture AVR, GCC started out with PROGMEM and special functions to access data stored with that flag. Later it introduced __flash which at least allows you to access the data in the normal way without special functions. It does mean that if you have a function that takes a pointer it has to be for the right bus, so the convention is to use function() for normal RAM and functionP() for program memory. Then you have functionPF() for program memory pointers beyond the 64k address register limi
Re:Rust band wagon garbage (Score:5, Informative)
On the contrary, Rust developers put a lot of thought into portability, which is why Rust runs on targets that look nothing like x86/ARM, AVR for example. https://github.com/rust-lang/r... [github.com]
It's true development efforts focus on x86 and ARM on Windows/Mac/Linux. That makes perfect sense, because that's where almost all users are.
I don't know what issues you're having with Rust on BSD but FreeBSD and NetBSD are tier 2 Rust platforms (builds automatically produced, but automated tests aren't run) and there are reports of recent versions of Rust working, for example, on NetBSD/PowerPC and bugs being fixed to keep it working. https://github.com/rust-lang/r... [github.com]
So when you say "Rust isn't portable" what you really mean is "Rust doesn't work on my particular combination of obscure hardware and OS". By that standard, C isn't portable either since gcc regularly drops support for rare CPU architectures.
Re:Rust band wagon garbage (Score:5, Informative)
Also, "Rust doesn't work" just means "no-one has fixed the bugs for my architecture yet", not "Rust *can't* work by design". (The story is different for other languages, e.g. Go, where the memory management and concurrent programming models simply can't be squeezed into tiny microcontrollers.) A systems programming language that aims to displace C/C++ does indeed need to be able to run everywhere, but it's OK, in fact necessary, for its platform support to expand over time.
Re:Rust band wagon garbage (Score:4, Insightful)
Every time I have a question about Rust's "memory safety" features (and admittedly, this may be a measure of the kind of question that I ask), the answer is typically "rewrite your program so that it fits Rust's ownership model".
That's precisely the reason why we moved away from C for data structure-heavy applications in the first place: so you don't have to structure your program around memory lifetimes or redesign algorithms/data structures so that they play nice with memory lifetimes.
Re: (Score:3)
Sorry to break it out to you, but if your code doesn't explicitly manage the lifetime of objects then it is not sound.
Sorry to break it down for you, if your code explicitly manages lifetime of objects then it is not sound for extension or maintenance.
You can not even add a cache of pointers to objects later, because if your explicitly manage(d) (the) lifetime of your objects kills one, you have a dangling pointer in the cache.
Your "I'm so superior because I know how to use the artificial concept of object
Re: (Score:3)
Rofl.
You seem not to grasp it. "Pointer ownership" or "object ownership" is an artificial concept that does not exist in managed languages!
So the seek for "object ownership" in C++ and alike is just an artificial crutch. And people like you think: because you know where to put the crutch you are smarter than the people who use languages that don't need such crutches.
Which part of my cache example did you actually not get?
Re: (Score:3)
I completely agree. All that this Rust-cheering shows is that the ones cheering do not get it.
Re: (Score:3)
Re: (Score:2)
Re: Rust band wagon garbage (Score:4, Insightful)
unsuitable for writing an operating system or system libraries.
There are things the high level languages just can't do well
Re: Rust band wagon garbage (Score:5, Informative)
unsuitable for writing an operating system or system libraries.
Ada is suitable for both operating systems and system libraries. In fact, it was designed as a system programming language, and was widely used in embedded systems.
There are things the high level languages just can't do well
Ada is not a "high level language" any more than C++ is.
I have used Ada, and I hate it, but not for the reasons you state. The big problem is verbosity and the amount of boiler plate code needed. It is tedious and not at all a fun language.
But none of this really matters, since Ada is pretty much a dead language. Nobody sane would consider it for a new clean slate project.
Re: (Score:3)
The first launch of the Ariane 5 went boom because of an overflow error.
No.
It failed because a 64bit float/double was squeezed into a 16bit int.
Would have been the same problem/crash in any language.
Re: Rust band wagon garbage (Score:5, Interesting)
My prediction is that new languages will keep cropping up, eventually one of them will dominate in the future. But I've seen no believable analysis that could determine which of the hundreds of languages will take over. That uncertainty makes it hard to bother learning these new languages beyond the fun of it. I can't really take Rust and others seriously until everyone else has taken it seriously for a decade or two.
This is why Rust gets so much interest. Many languages pop up. Of those almost none could even hypothetically replace C++ because none of them can target all the same domains that C++ can. People inevitably forget about one or more of performance, expressivity, don't pay for what you don't use, library writers, low level control and the multiparadigm nature. Not all applications need all or any of those, but you can't replace C++ across the board unless you have them.
So far Rust is the only one of those written by people who understand C++ enough to actually cover the same domains that C++ covers (c.f. go and Pike's whiny blog post about how C++ programmers such because they don't rush to the awesomenes of go).
That's not to say Rust is the one, but I think the interest stems from the crushing lack of C++ replacements that can't be trivally dismissed because they clearly fail to cover some key area.
I don't know why Ada never really took off. I think there's probably a mix of reasons. One is the early lack of tooling. Another is that it was in it's prime before people started to really care about memory errors in C (and C++), and before serious levels of exploitation were the norm not the exception. Possibly it also came before much of the internet and never had a chance to tap into the internet hype machine or get like minded people together.
Who knows?
Re: (Score:3)
They said that about Modula 2 and Oberon, too.
Hint: https://stackoverflow.com/ques... [stackoverflow.com]
Hint: google is your friend. Altavista was your friend, too!
https://marte.unican.es/ [unican.es]
Just saying ... no idea why 90% of all software developers are idiots, aka nitpickers or Fachidioten.
You okay? (Score:2)
I'm kinda worried about you now.
Whatever is going on in your world, I hope you talk to someone about it.
Re: (Score:2)
Why not? You can have embedded assembler, same as C (and C requires that to write an OS).
Re: Rust band wagon garbage (Score:3)
Re: (Score:3)
https://en.wikipedia.org/wiki/... [wikipedia.org]
"Modern" CPU architectures that mixes data and code have as much to do with vulnerabilities than languages.
Better yet (Score:5, Funny)
Why modern knives are still not as safe as spoons or q-tips?
Surgeons should use safety scissors! (Score:5, Insightful)
But seriously, "Mozilla" is an organization implementing colorful fancy stuff, which endangers safety most by being abused as "sort of an operating system", executing stuff by default that was just downloaded from somewhere on the Internet (JavaScript). It's funny how they, with their endless list of 10+ years old unfixed bugs in their bug-tracker try to teach other people programming more safely. I'm sure that using plastic Safety Scissors is the right thing to do, though - for exactly the kind of programmers Mozilla employs.
Re: (Score:3)
Re:Better yet (Score:5, Interesting)
Did you see some of the examples he uses as "evidence" of C++'s pitfalls?
std::unique_ptr<int> f() {
std::optional<std::unique_ptr<int>> x(std::nullopt);
return std::move(*x);
}
I mean, holy shit, who does this? Look, I'm not going to argue you can ever make C++ completely memory safe, but you need to at least find some examples someone out in the world might feasibly run into.
And he complains about how std container's [] operators are unchecked. Um, yeah, because bounds checking every access at runtime has a very significant cost, and C++ is often chosen due to its performance characteristics. If you want checked access, that's what the at() function is for (which he acknowledges, but glosses over). There are many cases where it's feasible to perform these functions safely due to other bounds checks, so that the per-access cost of the bounds check is not needed. A simple example is a for loop that iterates over a vector from 0 to < size(). No bounds checking needed there.
I'm not bagging on Rust. I think memory-safe languages are an important innovation, but I dislike how he seems to set up strawman arguments. C++ has a lot of legitimate issues without making up problems that don't really exist in most code I've seen.
Exactly Why Rust Failed (Score:3, Interesting)
> Did you see some of the examples he uses as "evidence" of C++'s pitfalls?
I have never seen an article, post, or talk given by Rust nutters that hasn't been a contrived example that would never been seen in real world production code.
The Rust techno babble scare tactics were never going to work on actual engineers who are the ones making the choice of languages to use for projects.
Obvious bias (Score:2, Insightful)
"Rust nutters", "techno babble", "scare tactics". You reveal terrible bias here. You won't be able to fairly evaluate Rust vs C/C++ if you retain this mindset.
Rust solves some problems extremely well. I already prefer it over C and C++ for everything I would normally use C/C++ for.
But it's very bad at some styles of programming. When I find that happening, I either adopt the Rust-centric style (even if I don't particularly like that flavour) or pick another language.
Re: (Score:2)
Obviously his examples are simplified to make it clear what's going on.
You can easily see how a similar bug could happen in production code. All that has to happen is for the programmer to think "I know that at this point 'x' can't be null" and unconditionally dereference it, and be wrong. It's not much different from regular null pointer dereference bugs.
Re: (Score:2)
The biggest problem with C and C++ is that there are too many people using it for use cases where they shouldn't. A knife isn't as safe as a q-tip, but the issue is too many people are using a knife to clean their ears (Yes I know you shouldn't use q-tip to clean your ears), because they feel only nubs will use such a safe tool, where only someone really skilled will use the dangerous tool.
This is the problem with programmers today. C/C++ shouldn't be safe languages, because they are low-level languages,
Re: (Score:3)
Before Rust it was true that you had a fundamental tradeoff between low-level control and safety. All generally useful safe languages required GC, and GC requires tradeoffs that take away some low-level control (see one of my other comments).
Rust changed that. With Rust you get safety without GC. You can write code that doesn't do dynamic allocation, or does dynamic allocation and deallocation at times you control. You can control memory layout. Your code doesn't get interrupted to do bookkeeping outside yo
Re: (Score:2)
Re: (Score:2)
I hear that there are even people that prefer to use a knife for some tasks! Shocking, I tell you! These must be complete morons.
I need more from a language (Score:5, Interesting)
Every time I see Rust talked about, the only thing that gets mentioned is memory safety. C++ is unsafe, Rust is safe, so use Rust. It is borderline hyperbole with many of the people who parrot it the loudest obviously not having significant experience in these "unsafe" languages.
I don't care about memory safety as much as you think I should. I've been using C++ for years, I'm good at it and am comfortable with its level of safety for what I use it for.
I need more from a language. Talk to me about what features Rust will give me that C++ doesn't. How will it help me solve my problems faster, write more efficient code, or write easier to maintain code?
Just spent couple of days tracking down a C++ bug (Score:4, Informative)
It was an obscure memory corruption due to a bad pointer in a large piece of code. Only happened occasionally, and was not picked up by Valgrind as it pointed into valid addresses. Symptoms did not suggest a corruption problem, which made it hard to track. (It did not just crash, which would be easy to diagnose.)
Add that to the security issues and C/++ should have never been born.
And it has been a long time since I have worked on a body of code that I wrote entirely myself. I take care to use very safe patterns, but still occasionally stuff up.
Re:I need more from a language (Score:5, Informative)
Sure. A few examples.
1) The`cargo` package manager. Using third-party libraries in a C/C++ project is enormously painful if you can't rely on Linux distros packaging them for you (e.g. because you support non-Linux, or the library is not packaged or the wrong version is packaged). `cargo` makes it far easier in Rust and in practice this means you see a lot more library reuse. The C++ standards people are just starting to talk about this.
2) Rust has pattern matching with built-in sum types. C+ doesn't have pattern matching yet and std::variant is hideous (and limited, e.g no references).
3) Rust has a powerful hygenic macro system that lets you write Rust code to manipulate arbitrary source code token streams. Among other things this provides powerful metaprogramming. E.g. serializing a value to JSON, complete example:
fn main() {
#[derive(serde::Serialize)]
struct Example { x: u32, y: u32 };
println!("{}", serde_json::to_string(&Example { x: 1, y: 2}).unwrap());
}
https://play.rust-lang.org/?ve... [rust-lang.org]
4) Easy parallelism. OK this is a kind of safety, but in Rust you can write parallel maps, reduces, etc and the compiler forbids data races. In C/C++, if you're sane, you're cautious about introducing parallelism because of the risk and the maintenance costs. In Rust you can write parallel code fearlessly.
Re:I need more from a language (Score:4, Insightful)
What package manager are you already using to manage C++ libraries for applications that must run on Windows?
Re: (Score:3)
I think even CMake as it is now is a massive improvement over the chaos that existed before. My company had to maintain dozens of .vcproj
Re: (Score:3)
vcpkg. Basically it's ports for Windows done with cmake and a thin cli wrapper to run it.
Memory safe like JavaScript, Perl, Python, etc etc (Score:2, Insightful)
The other thing Rust fanbois don't seem to understand is that MOST programming languages are memory safe. Their constant refrain of "you should use Rust because it's memory safe" is like you saying "you should buy a Ford because it has cupholders". But apparently they don't know that most languages are memory safe.
There might be some good reasons to use Rust. The evidence suggests that the users are clueless, however.
Re: (Score:2)
The Rust fanboys I know understand that. There's a reason why the original article is about C/C++. As a Rust fanboy myself, I think Java is a considerably better language for many applications (we need a COBOL for the 21st century, and Java is a good fit). Even Python is a better language for some applications. Perl just sucks though.
Rust has considerably more to offer than just memory safety though. See my other comment about that.
Re:Memory safe like JavaScript, Perl, Python, etc (Score:5, Insightful)
> The other thing Rust fanbois don't seem to understand is that MOST programming languages are memory safe.
They absolutely understand that. Rust is for when you can't afford a runtime system and garbage collector, and the alternatives are C and C++. For example, a browser or OS kernel. They don't mention Java, Javascript, Python, Go and friends because *it's obvious* that if you can use them, you should.
Re: (Score:3)
As for Mozilla "rewriting everything from scratch", maybe you should look at the aims of NGLayout back when Netscape Navigator was a thing, or why Servo is a thing today. It might help you understand.
Re:Memory safe like JavaScript, Perl, Python, etc (Score:5, Informative)
The other thing Rust fanbois...The evidence suggests that the users are clueless, however
Can we not?
Characterising something by only the most extreme examples you can find is what has poisioned political debate here. I found someone from $WING who said $BADTHING about $GROUP which makes them just like $DICTATOR so everyone from $WING is like $DICTATOR.
Characterising the users of rust by it's most vocal and ignorant fanbois is on the same level.
Rust is quite high on my list of things I'd like to learn but probably won't unless something changes. The combination of the machine model from C/C++[*] with memory safety sounds like an interesting combination, and its currently the only even vaguely mainstream language that offers it. Servo/Quantum has demonstrated it's not all hot air.
But apparently they don't know that most languages are memory safe.
Not all safety is buffer overflows. Some of it is threading problems, something that far fewer languages offer any help with. Bear in mind if you have to take a performance factor of, well, much of anything to get thread safety, you may as well write it single threaded and have the same performance with simpler code. What's interesting to me is Firefox Quantum, managing to parallelize something that 3 much better funded organisations (Apple, Google, Microsoft) failed to do (with Safari, Chrome, Edge). See here for a measured account including fixed C++ bugs that they reintroduced with the rewrite in Rust:
https://hacks.mozilla.org/2019... [mozilla.org]
I'm not likely to switch to Rust any time soon since it doesn't provide much compelling for me. My day job is a lot of computer vision code at the moment. Trusting user input isnt something I have to do, and the parallelism is of a much simpler sort that what Mozilla have to contend with. And Rust still doesn't provide some of the language facilities I find useful.
[*] the one time such an expression is appropriate.
Re: (Score:2)
Talk to me about what features Rust will give me that C++ doesn't. How will it help me solve my problems faster, write more efficient code, or write easier to maintain code?
I'm a C++ programmer myself (I've never used Rust for more than compiling some tutorial examples to see what they were like), and the thing that appeals to me about Rust -- at least in principle -- is the emphasis on robust compile-time error checking. I try to write my C++ programs such that if they compile, they are very likely to be correct, and contrariwise, if they are incorrect, their error(s) are likely to be caught at compile-time. This saves considerable time, since compilation has only one "exec
Because ISO 26262 does not recommend them? (Score:5, Interesting)
The ISO does recommend certain subsets of C and C++, though.
Namely MISRA C:2012 and MISRA C++:2008.
Re: (Score:3)
MISRA disallows dynamic memory allocation so you don't want to use it unless you're required to by law.
Re: (Score:2)
So all communication should be done with fixed-length buffers? 140 character text messages should be enough for anyone?
Re: (Score:2)
Why are you communicating directly out of the Functional Safety domain with characters?
Re: (Score:2)
We're not in the "functional safety" domain. I replied to an Anonymous Coward saying "dynamic memory allocation is an artifact of weak design in almost every circumstance."
Re: We're not in the "functional safety" domain. (Score:2)
Then why do we talk about safety?
By many ISOs, the term is very defined very loaded. If Rust and Swift can't play in this filed (e.g. because GC puts a system into an undefined state, even so shortly) then we should not allow these languages in the field, at least until a fully defined system is possible.
Re: (Score:2)
Memory safety is a reasonably well-defined term in software.
FWIW Rust can be used in even the most tightly constrained embedded systems. You can write code that is guaranteed to not allocate. You can also write code that manually allocates and frees (no GC) while being memory-safe. In the latter case you would still need to prove absence of OOM, or handle OOM.
Re: (Score:2)
OK, what is the maximum length of an email? An HTML page? A person's name?
Re: (Score:2)
Will your email client support a 1PB email?
Can your browser display a 10PB HTML page?
If not, we kinda agreed that there are limits.
What is left is to codify these limits.
Re: (Score:2)
Those limits depend on the resources available and are not, and should not be, baked into the software or protocol. It's a feature, not a bug, that a more powerful system can read longer emails, write longer documents, or view bigger Web pages. We wouldn't want to limit emails to 640KB because someone somewhere is reading emails on an old IBM PC.
C++ RAII is lipstick on a pig (Score:2)
int x
string msg = "The answer is " + x;
(Would be nice if any of the modern compilers could warn about this sort of thing. In the rare case that I really want pointer arithmetic I will be explicit. &x[0].)
Rust and Go boat that they are better than C++. That is not much to boat about.
Back in the 1980s efficient garbage collection techniques were developed in the Lisp community, which eventually went mainstream via Java in the 2000s and later .Net. There are very few applications that should not be usi
C++ means lots of copying (Score:2)
Might add that RAII C++ typically involves lots of copying of string and other data structures rather than just moving pointers around. So not efficient at all.
Re: (Score:2)
That is C, not C++. It is not RAII.
And it begs the question, in a complex system, whose job is it to free?
Re: (Score:2)
To be clear C++ is // copy.
string foo = "hello";
string bar = foo;
Re: C++ means lots of copying (Score:2)
What about that is not C++?
_my_ c++ compiler compiles that without complaint.
If your answer is âoethe developer must choose not to use unsafe constructsâ then youâ(TM)re already lost.
Re: (Score:2)
Modern garbage collection, as found in ART, Go and V8 is very impressive. Threaded and time-bound collection sprints mean that there's never a "stop the world" collection as used to happen in old Lisps and similar systems. So you almost certainly could get away with using that sort of language for most user-interface and server-side code. There is still a cost though: on average it costs about twice the memory footprint of a non-garbage-collected system, and it's very difficult (mostly due to constructio
Re: (Score:3)
GC languages are great for many domains but there are important domains where they simply aren't suitable:
1) All GCs require you to trade off between throughput, latency and memory overhead. For example Go optimizes throughput and latency but approximately doubles heap size. With Rust (and C/C++ manual memory management) you avoid having to make those tradeoffs.
2) Sometimes you have memory overhead constraints or latency constraints that simply can't be met by GC in a realistic configuration. E.g. Go GC opt
Re: (Score:2)
Point 3 also means that GC languages create lock-in. Once you've written a component that depends on GC, everything above it in the dependency stack (in the same process at least) pretty much has to use the same GC, which means the same VM and often the same language.
Re: C++ RAII is lipstick on a pig (Score:2)
For many, twice as much CPU is significantly cheaper than live-debugging production code.
No skills? Don't use C/C++ (Score:5, Insightful)
Basically, what he's saying is that most software developers don't have the skill level to use C/C++ in a safe way.
I'd probably agree with that.
There's a fundamental problem between C/C++ and the idea of abstraction: abstraction means you don't have to worry about details, yet in C/C++ details are critical.
Re: (Score:3)
Both of those statements are wrong.
Mediocre programmers can learn Rust, it just takes longer.
Good programmers still need Rust. You won't find high-profile C++ programmers willing to put their hand on their heart and say they don't have problems with unsafety. Pseudonymous forum commenters don't count. Here I am on the record: https://robert.ocallahan.org/2... [ocallahan.org]
It's by design (Score:4, Insightful)
Re: (Score:3)
It assumes you are adult enough to understand what you're doing
I reckon people who use such language are an absolute menace on the codebase because you way overestimate your own abilities.
If you want safe memory, then don't use C/C++.
No, that's absolutely 100% wrong. Your "C/C++" programs should be memory safe otherwise you have at best UB and at worse a really bad security hole.
If you want the type of functionality and memory-access that C/C++ grants - then you have to accept it's open to memory leaks.
Wait
Re: (Score:3)
Re:Not true (Score:4, Informative)
You can build an application with "no_std" feature meaning it will be a static executable without any dependencies and without a large standard library. Look for example at the documentation: https://doc.rust-lang.org/core... [rust-lang.org]
I thought the examples are silly (Score:2)
Overall, I'd give the article a C+ for trying, but overly peda
Re:I thought the examples are silly (Score:5, Insightful)
"If you don't make mistakes, you won't have bugs" is a dumb defense.
NSA/Microsoft Rust (Score:2)
Re: (Score:2)
He's saying that the Cargo registry lives in Github, and Microsoft owns Github, so Microsoft and the NSA can tamper with it.
The reality is that the NSA can also tamper with the source code for your favourite C compiler, but they have little to gain and a lot to lose by doing so. It wouldn't be difficult to detect.
Lazy Stupid Programmers (Score:2, Insightful)
I have been writing software for over 30 years, and dammit I have yet to forget to free after I malloc in released code!
There are a plethora of tools to check that for you! Use them!
It seems that people want to write the most insipid, stupid code they can, and they cant seem to be bothered to look at and check to make sure memory is freed after they are done using it!
Or they want to write arrays that are endless because they are to lazy to examine, or even estimate how much memory any operation will use
Ever
Re: (Score:3)
Also C is the language that does run anywhere and is efficient anywhere. It is not some posh project made for looks and style. It is a hardcore engineering tool that expects you to know what you are doing.
Re: (Score:3)
> I have been writing software for over 30 years, and dammit I have yet to forget to free after I malloc in released code!
You don't know that. Or can you offer me a machine-checked proof?
> Everyone loves to think that there will be plenty of memory, you can never run out!
Not everyone. In particular, not the designers or users of Rust. Are you sure you've been paying attention?
> C is the smallest, most efficient, most elegant language ever built
It isn't the smallest and it's only your opinion that i
Re: (Score:3)
I have been writing software for over 30 years, and dammit I have yet to forget to free after I malloc in released code!
Either you write in a domain where this sort of thing is pretty easy (scientific programming is a good example) or you're full of shit. Given the colossal chip on your shoulder I reckon it's the latter.
Which makes you, like many others here, an absolute menace on the codebase. Actual engineers, not coders or hackers, accept that humans are a thing and they are imperfect anf falliable. Tha
Re: (Score:2)
Well yeah thats his point. Incompetent users are "holding it wrong"
But nothing will make them all super geniuses over night.
Most code these days can be in completely memory safe high level languages.
Re:Training Wheels ... (Score:5, Insightful)
well, yeah, but "incompetent" people (a less insulting way to say this is "beginners") are, uh, cheaper, so they're getting hired anyway. (it's always been like this, btw.) so might as well give them a language that lets them express their ideas safely.
if this upsets you, i think you should re-evaluate your relative value to the world. there just isn't much demand for omgwtfbbq-efficient C these days when you can scale up the hardware fungibly for a fraction of what a competent programmer will cost per year anyway.
there are specialty fields where it matters, of course, and godspeed if you're in one of those. but the majority of the money is in serving ads to idiots and no one in that food chain gives a flying fuck.
Re: (Score:3)