will rust replace c and c++ from the point of view of software engineering
We haven't replaced the COBOL yet. New jersey government is urgently recruiting COBOL developers.
21 Likes
Technically it could, but rewriting billions of lines of existing C/C++ code and re-training existing C/C++ programmers is a huge cost, so it's unlikely to happen.
10 Likes
Obviously C and C++ are not going to be abandoned just because Rust shows up. C and C++ will be with us for a long time to come.
I don't think anyone in the Rust community has that kind of overthrow in mind. Rather the name of the game is symbiosis. Rust can make use of all the existing C/C++ libraries and infrastructure. Rust can be used to extend existing C/C++ programs. Hence the emphasis on drop dead easy interfacing between Rust and C++ (Compared to many other new languages). Rust and C++ can be living together for a long time. As demonstrated by the application the spurred development of Rust, Firefox.
Of course we would like to see new developments make use of Rust and it's correctness features rather than continue forever in the world of UB that is C/C++. Which is the approach our little startup is taking. That will happen more widely, who knows how quickly.
11 Likes
The question as written is of course far too simplistic for any short answer to be correct. Some projects will be written in Rust, some in C or C++, and some existing C/C++ projects will be rewritten in Rust, and those are going to remain true for the forseeable future (i.e. probably decades).
However, there is a strong sense of "replacement" that could plausibly happen. Today, there are many greenfield software projects where C or C++ is the best available language choice when all technical merits are taken into account (including things like ecosystem maturity and help forums, but excluding FUD and misinformation). There are already some greenfield projects where C or C++ was once the best choice but Rust is now a clearly better choice. I do believe it's possible that Rust could become the best choice for all of the greenfield projects where C or C++ was once the best choice. That is my direct answer to OP's question.
Of course, that's hardly a guarantee that it will or should happen, much less that we should be speaking or thinking of "killing off C++" as if that was our primary goal or victory condition. I think it's far more constructive to say Rust is about raising the bar for all aspects of systems programming, which includes encouraging existing and future languages to do better. A perfect example of this is C++ considering its own lifetime/borrow checker system. While it obviously can't provide guarantees as strong as Rust's, and it might contribute to some projects staying with C++ instead of switching to Rust, C++ adopting "lifetimes" would still represent a victory for the Rust project insofar as the Rust language helped make C++ code safer in practice.
Notice this intentionally excludes projects that are only choosing C or C++ because it's what their company and programmers are already familiar with (like my day job), or increased compatibility with other systems (Rust's FFI is great, but C++ calling C++ will always be easier than Rust calling C++), or projects which choose some completely different language like Go, Python or Javascript. All of which are extremely legitimate reasons to not choose Rust.
This also leaves out the very real possibility that Rust will help inspire some future SuperRust language that is objectively superior to Rust in ways we can't simply bolt on in a backwards-compatible way before Rust displaces C or C++.
16 Likes
FWIW, type-theoretically speaking, there aren't too many places on the lambda cube left to go to. So once some form of dependent types exists in a mainstream and widely adopted programming language (and perhaps other forms of type checking eg session types), great type-theoretical innovations will either stop or be drastically reduced in frequency.
So what's left? Features that are useful in practice, but that are not on the type level eg new forms of side-effecting that can give stronger guarantees without going Full Monad.
On the other hand, a language that looks like a crossbreed between Rust and a descendant of Idris might replace Rust one day, if such changes cannot be made to Rust itself in a backwards-compatible way.
4 Likes
I've been programming C++ for thirty years now, and for the last 20, I've been looking for a viable replacement. Rust is the first one to show real promise in it's consistency across language and libraries, while approaching or exceeding performance capabilities of C.
As of the last year or two I've been recommending Rust over C++ for new development on a variety of target applications, particularly back-end communications on desktops and larger embedded systems (i.e. embedded Linux boards). As async/await stabilizes and grows, there will likely be a Rust incursion into server back-ends.
But there are a variety of targets for which C/C++ still excel, like image processing, numerical apps, and deeply embedded/RTOS/bare-metal. Rust is making inroads there, but for safety-critical systems, although Rust would be great, it will take years to convince managers and inspectors. Time makes for a more powerful argument than a spec sheet.
That said, I maintain hundreds of thousands of lines of C++ code, and I'm not telling anyone to rewrite apps or libraries that work well regardless of the language. I assume that I'll still be writing some C++ until I sail off into the sunset years from now.
But the comparison to just C/C++ is a little misguided. Probably half of the Rust work that I've done in the last few years has been to replace apps in other languages like JavaScript and Python that got bogged down by poor performance. People will really start to notice when you give them an app that 20-50x faster than their old one, but doesn't crash with segfaults. So the oxidation of the software world will continue.
22 Likes
Eventually yes, but I think that's a long way off. There is a lot of code written in C & C++ and it's hard for a company like Microsoft to ditch their entire OS and rewrite it in Rust. It would probably take 10 years to rebuild Windows from scratch in a new language while maintaining compatibility with programs that currently run on Windows. But the operating system that runs VR and replaces windows.. could very well write it in Rust. Google's new OS is using Rust inside it.
I think the one workaround to this is to create a better transpiler that compiles C++ to Rust.
There are a couple great starts here:
But both have issues that need to be fixed before they can really be used. For example, c2rust loses all comments during translation. crust only works one file at a time.
But if a transpiler could translate code and leave you with something that will work as is, is still usable, and highlights sections of code that should be re-written using Rust's safety features, and runs out of the box.. then who wouldn't want to run their code through it and switch to Rust, clean up potential memory safety issues and optimize bottlenecks that could use a performance boost and take advantage of Rust's ability to optimize certain things that are such a pain that most C programmers just do them in an unoptomized fashion to avoid the significant hassle?
One place I do believe large parts of code will be rewritten: Anything that requires high security, like financial systems. One memory safety bug there that they don't know about and you lose billions of dollars. Considering roughly 50% of all bugs are memory safety issues.. I'd say worth the rewrite.
1 Like
I'm not so sure about financial systems specifically. Making a change to a code base is viewed as a risk over there, which leads to scenario's of core financial systems still being written in COBOL (and web interfaces for eg online banking are more or less tacked on on top). In a place where that is true, even something as compelling as Rust will not move the immovable stone that is "best practices".
1 Like
It could, but there is still a long way to go.
i hope it will replace c and c++ since rust has a good package manager and inbuilt testing tools which help the save time during test and maintains of software
1 Like
I don't think "Replace" is the right term here, I'd probably word it as "Rust will supersede C and C++ over time".
In the 60 or so years that people have been programming there haven't really been any mainstream languages which get replaced, places are still running systems written in COBOL after all! It's more that projects start to get written in the newer language and over time older languages fall by the wayside.
A lot of really good quality stuff has been written in C (Linux kernel, etc.) and C++ (tensorflow, the JVM, etc.) and I doubt those projects would even consider switching to Rust. Rewriting a project in a new language has significant financial and technical costs (you're re-implementing complex things and it's easy to (re)introduce bugs, it costs a lot of engineering time, etc.) , and for a lot of use cases the potential benefits just don't outweigh the real-world costs.
6 Likes
The answer is no to that, that it will replace all C/C++ domains. Rust is a viable replacement for C/C++ in application projects where C/C++ is already doing less well because of lack of good libraries. Typically, these are new projects where they decided to use Rust instead of C++. For example Pijul https://pijul.org/, decided to use Rust in their project where C++ would be an obvious contender. We will see more projects like that choose Rust because C++ doesn't have as good libraries (C++ doesn't even have an own socket library today). Another typical example is that Rust is often the better choice is web/cloud applications. It's mostly the ecosystem where Rust beats C++ and with C++ you constantly have to search libraries and also check their licenses ((L)GPL is often not an option for many). Rust is a more batteries included language than C++ which will displace C++ in certain domains.
Now there is a domain where Rust will never displace C/C++ and that is embedded bare metal programming. The reason can be explained in several posts in this forum, like How to implement a single linked list in os/bare metal? - #5 by Yandros. It is obvious that things that are trivial in C/C++ becomes absolutely horrible and over complicated in Rust, and this is because of the nature of the language. It simply makes things more complicated for no benefit while also not more safe C/C++ because you have to use unsafe code.
I have to strongly disagree with that assessment.
Having been involved in a lot of small, real-time, embedded, safety critical, projects since the early 1980's, in various languages, my observation is that they do not use dynamically allocated memory. In such a system you want to know where everything is from the get go and have it sized accordingly. There is no place in such a system for the timing indeterminism or potential failure of a memory allocator let alone a garbage collector.
I can write such code in Rust without using "unsafe", with the extra correctness afforded by it's type system.
For larger embedded systems, more code, more data, more threads, more cores, one can write Rust as usual. Whatever it is you want to do that you think needs a linked list can be done. As it is for writing any other code. In fact that is what I am involved in now.
All without using "unsafe". Or at least very little. Don't forget use "unsafe" does not mean your code instantly becomes as bug ridden an dangerous as C/C++. It's there to strictly confine areas of code that need serious inspection. A clear win over C/C++ where one needs to apply serious inspection to every line.
Then the likes of Intel would like to disagree with you. They put their support behind the Embedded Rust Working Group: Embedded devices working group - Rust Programming Language
And finally, if you don't buy into what I say, do read Cliff Biffle's story of implementing VGA graphics on a tiny STM micro-controller: Rewriting m4vgalib in Rust - Cliffle. A task which he had prviously done in C++. A fine example of the kind of real-time embedded code I think you are alluding to.
Cliff's conclusion: The Rust version was faster and more correct. It showed up a hidden bug or two in his original C++ version.
9 Likes
It doesn't matter and there will a few embedded Rust projects but Rust will never displace C/C++ in the embedded domain. Resource handling is more complicated in Rust once you get past the very small systems that only pokes a few ports.
Then we have all the chip and IP vendors that often ship some kind of framework for their IP. These are always done in C/C++ for compatibility and because of this most people will use C/C++. They don't want to port all headers to Rust, they just want to begin as soon as possible so they continue with C/C++. If someone ships only a Rust framework with their IP, they will probably see their sales go down.
Rust totally replacing C/C++ in bare metal will not happen, regardless if it is safer, or few successful projects or whatever. If you have been in embedded SW engineering since the 80s, you do know that. C/C++ will be dominant in this domain for many years to come and if a language displaces them it will not be Rust and Rust will not even be widely adopted language. Also the available jobs where they seek Rust programmers for embedded projects is virtually zero, plenty of C/C++ though (almost only that actually).
Rust will not displace any language in the application domain either, however Rust will have a larger share here.
Well, once we get past the very small system, the argument that resource handling is more complicated in Rust also kills it for any normal programming. Many would disagree with that.
Funny you should bring that up. Turns out that ARM is very interested in supporting Rust on their processors. Sadly I can't find you a link to the presentations on that just now.
I know no such thing.
In my time. The incumbent language, Coral, was displaced by Ada. Ada was displaced by C. C became C++ in places. In other realms PL/M, Lucol languages were displaced by Ada. Ada was displaced by C.
I don't doubt C/C++ will be around in embedded systems for a long time. On the other hand I see no reason why Rust cannot make big inroads into that space.
Why on Earth not? You make it sound like you know of an even better language for the embedded space that is about to take over. Love to hear what it is.
1 Like
Resource handling in bare metal systems is very different from resource handling in applications. My link in my original post in this thread is a typical example of that. You often need to resort to various tricks, many that would be inherently unsafe in the realms of Rust.
Please be aware that you are pontificating to people with many decades of experience in bare-metal programming, who have repeatedly disagreed with your personal conclusion. I've been bare-metal programming for 58 years.
13 Likes
Although I have zero bare metal experience, this disagreement seems especially strange to me because I've repeatedly seen posts from bare metal veterans claiming that the Rust development experience is already vastly superior to C/C++ today (at least on their favorite platforms, which admittedly tend not to be the best at C/C++ support either). Unfortunately I can't recall where to find any specific quotes from those veterans at the moment (other than what's in this thread).
I would've expected the disagreement to come from some completely different domain like numeric/scientific computing where Rust's current lack of e.g. const generics makes its suitability still a largely theoretical claim with no complete, concrete prototypes.
Meanwhile on embedded, we have things like compile-time proofs of thread safety on Cortex microcontrollers with zero runtime overhead, which seems totally impossible for C to ever achieve, and there are multiple production users of Rust which use the term "embedded" in their blurb. And that's just citations I can recall off the top of my head.
10 Likes
Use of "never" or "always" is always wrong. Everyone knows that you never say never.
Seriously though, it is indicative of your arguments coming from a place where you see it as a black and white thing whereas others see a little more nuance. Personally, I find it difficult to believe that Rust will not displace/replace many, many usages of C/C++ over time. I remember in the '90's/early 2000's almost no one used Python. Trying to convince the suits to allow it to be used when they already had Visual Basic, COBOL, C, Delphi, WFL, Rexx, etc. was almost impossible. Fast-forward a few years and "Whoa.....Python, the #1 used language for ML etc".
You, or many others, or even I, many never make use of Rust and it could still in a few years take over just out of simple change in inertia which can, and does, happen suddenly. After all, we all die and there is nothing that says the young'uns need follow in our footsteps.
6 Likes