In Rust We Trust: Microsoft Azure CTO shuns C and C++ Microsoft Azure CTO Mark Russinovich has had it with C and C++, time-tested programming languages commonly used for native applications that require high performance. On Monday, Russinovich urged the technology industry to leave C/C++ behind. "Speaking of languages, it's time to halt starting any new projects in C/C++ and use …
I'll stick to C when unavoidable, C++ where needed and scripting languages everywhere else.
from a practical standpoint, that makes the most sense, especially if you are in IT and need to solve problems as they appear and keep things running the rest of the time.
re-learning "New Shiny" everytime Micros~1 announces something is a colossal waste of time anyway. I'm thinking Silverlight, and that "Metro" thing. BOTH ARE BIG FLOPS.
And I stuck with C++ for any windows progs I wrote, which was not many, and they run fine on 7 too.
Still they ARROGANTLY chose to "Deprecate" C and C++. Who died and made THEM *GOD* ???
"We welcome the community to implement their own custom square rounding add-ons. Of course we will supply some, too, so that we can produce shiny demos of a wheel rolling, but we are going to forefully avoid any blame towards the core square team when the add-ons start to fall apart at high speeds."
v5 telemetary added
v6 compulsory registration added before wheel could be activated. Also allows chat with other wheel users
v7 use of wheel downhill now requires optional micropayment
v8 wheel is no longer available to purchase but as pay-as-you-go
-> Rust seems less prone to potential memory corruption bugs and this makes software less vulnerable.
It only makes rust programs less vulnerable in those areas. It does nothing to stop bad programming in general, and there are plenty of bugs around like that. Does it stop hardcoded credentials being part of a program, AKA a common Cisco bug? Can a rust function be written to return true even if it doesn't actually do anything?
Tooling to prevent credentials from being hardcoded does not need to be language-specific. I work at Microsoft and we have such tooling baked into our processes. You have to run these checks before anything hits the field. There are plenty of similar tools available in the community.
As for useless functions in Rust, I'm not sure, but the compiler is very good at spotting when something is not used.
Just in case you think this tweet was all talk, what little coding I do at work does sometimes involve some Rust, and I know plenty of colleagues who practically write little else.
The point I was making, with some simple examples, is that Rust does not automatically make your programming less vulnerable. It handles certain things better, and that is good. But it is very wrong to make the over-generalised statement as in the article that "Rust seems less prone to potential memory corruption bugs and this makes software less vulnerable", as though that is the *only* or most important feature making software vulnerable.
I would not want anyone to think "we are programming in Rust so we are secure (or more secure)". That is far too big a jump.
But, you are doing the same thing, only in the other direction. The statements in the article about "less vulnerable" are correct, as is your statement that Rust does not make programs fully secure. To me, it seems like you are deliberately trying to downplay the advantages of using safe languages like Rust. The benefits are real - such usage *will* make many (most?) programs less vulnerable. Not completely invulnerable of course, but definitely LESS vulnerable.
There are other types of gotchas in most languages. One that I found a couple days ago in my C code is years old:
wrong: ... 1 << n ...
right: ... 1ull << n ...
(64 bit compilation)
If I recall correctly integral literals in Rust are u32, so the same problem exists there.
You have fallen into the trap. You are a good example of what I wrote about people using Rust saying that automatically makes them more secure.
Rust has certain features, but it can not stop you writing insecure programs. Let's say you have the most memory-safe Rust program out there, yet your shoddy programming still has an error - let's say you accept an authentication token that you should not or you allow access from an IP range that you shouldn't because you can't calculate a netmask properly. Congratulations. Your memory safe program will not save you, yet you think you are safe just because you are suing Rust. These are trivial examples that I see today in all sorts of programming "examples", and no doubt I will see them in Rust too.
That belief is what is driving the enthusiasm for Rust despite being completely untrue.
I think the one selling feature to NOT adopt Rust is interoperability. That, and a learning curve for your existing experts in C and/or C++ (that last one bothers ME a LOT, wasting weeks or months getting back what I already have with the existing tools and programming lingos).
So, do we really need to re-write a large number of existing libraries code bases in Rust so we can use them again? This may or may not be justified (I really do not know) but it IS a concern, at least for me.
But it is very wrong to make the over-generalised statement as in the article that "Rust seems less prone to potential memory corruption bugs and this makes software less vulnerable", as though that is the *only* or most important feature making software vulnerable.
0/10 for reading comprehension and critical thinking.
The quoted statement in no way implies your gloss.
Of course it doesn't. But considering that memory bugs comprise 70-80% of security vulnerabilities this alone is a huge step forward.
Also, the stability of the application will be rock-solid if programmed in Rust. No more time wasted with looking for that memory pointer bug somewhere in your 200K LOC codebase. If it compiles it works.
In answer to your question, no Rust won't help you against application logic issues and never claimed it did.
However it will stop your code from suffering the mass of bugs that plague C & C++ and are directly caused by the language syntax - null pointers, double frees, buffer overruns, data races etc.
Most people regard that as a good thing.
null pointers, double frees, buffer overruns, data races etc.
I rarely see that kind of bug. Usually I see infinite loops and bad logic. Easily found and fixed. Rust would be "about the same" I'd think.
Those pointer-related issues can also be resolved in C++ by use of abstract objects with reference counts.
/me once solved 'asynchronous allocated memory lifetime' bugs by using ref counts on each allocated buffer instead of trying to manage things with state variables. The end result is that the code became faster as well, which most definitely sold the idea to everyone. It seemed to me to be the obvious solution.
Count up half the CVEs in the Linux kernel and they are *exactly* that sort of thing. Since kernel programmers aren't exactly green around the gills others projects probably have it even worse.
And yeah C++ has templates to mitigate some issues but it doesn't solve them. I've seen code where a smart pointer has yielded its raw pointer and for another piece of code to wrap the raw pointer in its own smart pointer, causing 2 reference counts. I've seen enormous quantities of badly written multi threaded code where data isn't guarded properly by threads.
The C++ compiler doesn't give a shit about any of this whereas the Rust compiler would kick your ass. The net result is safer code from developers who spend less time working on stupid race conditions or other rare bugs and more on fixing application logic issues.
When I first started coding in C (in 1976 at UC Berkeley when the manual was a few photocopied sheets), Pascal was used for teaching. The difference was that Pascal assumed the programmer didn't know what they were doing and C assumed they did.
I think it's a much bigger problem that programmers don't understand the security aspects of the libraries they use. For example, open an HTTPS connection AND THEN call the function that checks the cert is valid.
As the quotes in the article and elsewhere point out, Rust is currently the language of choice for new projects that would have previously been written in C/C++. But migrating an existing system from C/C++ to Rust is difficult. It is a replacement for C/C++, not a successor.
In July at Cpp North, Google announced it is working on Carbon as a successor which will be backward compatible with C/C++ and would make it much better for conversions. But when or even if it emerges from the lab is up in the air.
Addressing some of the comments, rest assured that C and C++ will still be available if you want them. Heck, Fortran and COBOL are still available.
Also rest assured that bad programmers will still be able to write bad code regardless of the language.
No, it's a successor. It will obviously take a long time before Microsoft has rewritten large parts of Windows in Rust. But I believe they're well on their way.
I do wonder why they're keeping quiet about it. Maybe Heijlsberg is cooking up some Microsoft derived version of Rust. Who knows.
Its not a successor, because Rust doesn't interop with C, you can't write a library in Rust and call it from C..
Holy fuck, you can! That's pretty cool. This means one could take a common library with potential pitfalls, lets say libpng, implement it in Rust and provide the same API for existing C consumers of that library. That's pretty dope actually.
Having said that, there are quite a few unsafe declarations in the example I was reading.
Rust has very good interoperability with C and C++ and tools for generating bindings too. If you want to see a mad example of this, check out the Redox OS - they wrote a C-lib in Rust with C bindings so literally you compile and run C against a runtime which is Rust but exposes stuff like strcpy(), malloc() etc
I don't think you'd ever want to port code that works unless you have a very sound reason to do so. That's whether we're talking Rust or some other language. A sound reason might be the old code is broken, hard to maintain, non-performant or new requirements are so substantial that you'd have to rewrite anyway. At which point you may as well consider it at least.
As for C and C++ I don't believe there is any way you can fix those languages. There is no superset which can be backwards compatible because the issues are baked into the language. Throwing new keywords or semantics at the issue doesn't fix the existing code.
I don't think you'd ever want to port code that works unless you have a very sound reason to do so.
Right. We have plenty of data showing that rip-and-replace is expensive and risky. It's extremely easy to introduce new implementation bugs, and often existing applications disagree with whatever specifications might be available (and usually there isn't much) in ways that business processes depend on.
Also, Rust isn't available on many "legacy" platforms that are still in use.
I like Rust for new projects where fast native code is called for, provided it's fully supported on the target platforms. And it can be integrated with existing projects where you're developing a new component with a clean interface to the existing code, provided you can budget the time to create (well-designed) bindings. But few people seriously consider rewriting large projects.
Agreed, but with the Linux kernel things may be different.
One of the kernel's unsolved problems is its license. Gpl2 was OK in its day, but it's problematic now. A Linux rewrite in Rust would also be a relicensing opportunity.
I've no idea what license would be best - that'd be one for the kernel community - but if they wanted to relicense it that apparently does mean at least a partial rewrite, either to overcome problems of contributors having since passed away, or those who don't agree to relicense their contributions. If there were the motivation to do it, doing it in Rust where rewrites are needed could be a good idea. The language change certainly makes it clear that it's a rewrite, as it places a clearer marker between new and derivative code.
You can always auto-translate C/C++ code to Rust. The issue is you're left with lots of unsafe code or you have to tidy up your memory ownership to satisfy Rust's strictness (which could involve big architectural changes to pull off cleanly), however the fact your code doesn't already satisfy Rust's ownership model IS a valid reason to call it broken if you care a lot about security, and will make it easier to maintain if you reduce the firehose of CVEs.
As for Rust being difficult to learn, it isn't really. It's more accurate to say it's difficult to learn how to code in a memory safe way and Rust happens to force (or at least strongly convince) you to learn that fairly invaluable skill. I'd even say it's much easier to learn the skill with Rust as a crutch rather than spending years of your life debugging mysterious memory corruption bugs as punishment for not being born with the skill.
This is it.
We could have a language based on the nature tongue of the programmer, where programmers explicitly describe what they want the software to do, and garbage will still be created.
I think a lot of the time (I'm guilty of it, I know others are) people dive in to languages like they're the be all and end all, without ever first considering the structure and shape of the software. Which then means you go and create something, test it, then discover issues. At this point then you're shoehorning fixes in to what you've made to make it work, and for it to pass "tests", and you end up with a mangled mess of software full of sticking plasters and workarounds. Just because you didn't bother to plan what you wrote, you didn't plan better methods of fixing issues you've caused.
Languages aren't the problem. The problem are the programmers.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
