Not saying Rust is flavour of the week but this happens with a new language every couple of years. Everything doesn't need to be rewritten. You switch languages, you might fix some existing bugs but you open lots of other ones.
Not saying Rust is flavour of the week but this happens with a new language every couple of years. Everything doesn't need to be rewritten. You switch languages, you might fix some existing bugs but you open lots of other ones.
There's a lot of this software. And until recently C and C++ were more or less the only viable options for writing it. Now there's Rust, and it has the potential to bring rates of security issues down to the levels of other memory safe languages (or even lower - Rust actually has protections against things like thread-safety issues that languages like Java don't).
If the language didn't matter, then we'd all be writing in assembly code. It can make a big difference.
I think that's very debatable. Certainly there are classes of bugs with C code that don't exist in other environments. And addressing that is worthwhile.
But "security issues" is a VERY big bucket, and most of them (and frankly most of the most dangerous) aren't about memory protection or heap management at all. Java doesn't prevent you from exposing a database with a default password. Node apps can have XSS vulnerabilities. Access to a Rust app can always be phished.
I know those all seem like specious examples, but the point is that you're using a very narrow definition of "security" (to mean The Stuff Rust Addresses) in one sense, while using a very different definition (Stuff That Is Really Important For Software To Do) in the premise to your argument.
The space between "well-written C++ code" and "well-written Rust code" is a very different number in those two spaces.
And in the one that actually matters... I just don't think it's nearly as big as people like to imagine.
But then there is a LOT more C/C++ software as well, so it makes sense that when you have a lot more code you'll also have a lot more bugs.
> than (similarly well written) software in other languages.
Why isn't that similarly well written software being used instead of the C/C++ software when the latter ends up with more bugs?
> And until recently C and C++ were more or less the only viable options for writing it.
I do not think that this is the case, there have been alternatives for pretty much as long as C existed. For example Object Pascal existed for decades before Rust and while it doesn't have as many compile-time guarantees as Rust does, it still is safer than C and C++, provides a similar amount of functionality while not losing in terms of low level functionality. Yet outside of a few exceptions (mainly during Borland's heyday) people still went with C or C++ despite those languages not providing anything special compared to it.
And there have been other languages too - i've seen Ada being brought up often as a much safer language (safer than Pascal too) with a strong type system, yet still being usable even on tiny devices.
What makes people stick with C and C++ when other solutions existed for years and how would Rust change that when other languages apparently failed?
70% of C/C++ security bugs are memory management bugs. Those don't (for the most part) exist in GC'd or other non-manually managed memory languages.
> Why isn't that similarly well written software being used instead of the C/C++ software when the latter ends up with more bugs?
Performance and low level control. Familiarity. etc.
Rust has the ability to compete with them. Other languages don't. So it's ripe for distrupting projects that are normally written in c.
Yet C and C++ still persisted. What makes Rust different this time?
Rust has more advantages than Pascal. A single implementation. A decent package manager, lifetimes, sum types, all the infrastructure around sum types etc
And C and C++ (especially C++) were not standardized for a long time and even after they were, most programs relied a lot on compiler-specific behavior.
Pascal does have sum types (called variant records) and AFAIK had those since the beginning. Not sure about how exactly Ada does its memory management, but AFAIK it isn't a free-for-all like in C or C++, most dynamic objects are stored in containers which handle memory and any custom memory management must be done in explicitly designated ways (which it doesn't sound very different than Rust's unsafe code).
So while Rust does add some stuff, i do not think that they are that much of an improvement over other existing languages (remember that many thought C was a step backwards compared to what other languages provided even at the time). Rust may add a lot compared to C, but very little when compared to other languages.
Also note that i brought up Pascal and Ada as examples here, but those aren't the only alternatives to C and C++ that existed, just a couple that came to my mind. Of course there have been other languages.
Which is really what i refer to above - compared to C or even C++, Rust does add some things but other languages that existed for years (decades in some cases) added to C and C++ and compared to those Rust doesn't add that much (which isn't the same as adding nothing). Yet these languages weren't really adopted and people remained with C/C++.
Do you really think that what Rust provides will succeed in making people adopt it when other languages failed (and let's be honest - while Rust adds some stuff it isn't like it has all the features other languages have either)? Is it even a matter of features (be it about memory safety or anything else) in the first place?
Given the ever broadening adoption of Rust, I'd say it'll definitely have a large foothold. I don't know that anything, no matter how good it is, will every fully replace C or C++. But I think a lot of projects that don't need a specialty compiler (embedded or stuff like game consoles) will start picking up Rust instead of C or C++.
The only functionality standard Pascal offers is the simplest "case" statement where you can match against the variances with only little more functionality than C's select statement (you can have multiple values per case and you can use ranges), but nothing more than that.
In modern Object Pascal it might be possible to implement the functionality using generics and anonymous functions (currently only available in Delphi but soon also in Free Pascal), but AFAIK there isn't any functional programming-like functionality out of the box. In general Pascal is largely an imperative programming language and even in the more advanced dialects there is almost no functional programming functionality.
Which makes me wonder how much programmers who use C really care about those features in the first place.
I consider this one my biggest concerns about adding a Rust dependency to a core package. Especially when in https://forge.rust-lang.org/release/platform-support.html "Tier 1" is so small.
Pascal, by contrast, simply didn't offer any compelling advantages.
It has all of the safety characteristics of a VM language but its low level with no runtime. Its a direct replacement for C with all the performance and modern design of languages like Java and Go. And it uses LLVM so FFI with other languages that compile to native is simple and zero overhead. You can even do whole program optimization (LTO) on the combined binary, that's huge. Trust me the hype about Rust is real.
Much more real than the hype around Go, which to me just feels like yet another GC language. The hyped AOT compilation is nothing profound. Since the GC forces Go to have a runtime anyways IMO they should have gone all the way and just used JIT. And Go doesn't use existing C compilers so FFI has overhead, can't be optimized together at a bytecode level
(Not that I'm personally a big fan of all these call to rewrite in Rust posts, there's a reason the Rust subreddit discourages ”X should be rewritten in Rust” posts)
There isn't really a trend, those who can are doing it in C++, those who can't are teaching us about the wonders of rewriting in a more fashionable language.