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.
@wolfetone
Actually you are talking about the DESIGN of the application being faulty. Yup.....I agree.............
............but that ship sailed long ago with the so-called "Agile Manifesto"...........
No....in place of DESIGN we now have an incrementing wall of yellow stickies with "user stories"!
DESIGN.....so.o.o.o.o.o.o.o twentieth century!!
......and, of course, Rust is a long, long, long way from solving this recent problem...........
Mark Russinovich (acquired by MS by buying out his company) has more programming credential in his little toe than most programmers acquire in a lifetime.
Even his wikipedia biography doesn't do him justice: https://en.wikipedia.org/wiki/Mark_Russinovich: 20 years later, his Winternals utilities are still in use.
He is incredibly knowledgeable about programming in general and the Windows internals in particular. He co-founded Winternals and wrote the sysinternals suite. Microsoft bought Winternals basically to acquire him. He has since moved on to become the big cheese in Azure.
The Sysinternals suite and his technet columns are invaluable resources.
On top of this, he has also found time to become a successful novelist as well as writing multiple non fiction books about coding and contributing to several IT magazines.
If you think you know more about software development than him, you are probably wrong.
Mark is awesome.
His friendliness, intelligence, clarity, wittiness, kindness, etc., are truly intoxicating. Every time that I have interacted with him, I have felt both fan-boy exhilaration during the engagement and fan-boy sadness at parting.
I wonder sometimes how much more forthright he might be if he were not bound by Microsoft. I wonder, too, how much better Windows and the rest could have been if he had been in the right places at the right times.
Mark Russinovich (acquired by MS by buying out his company)Bjarne Stroustrop has more programming credential in his little toe than most programmers acquire in a lifetime.Even his wikipedia biography doesn't do him justice:
https://en.wikipedia.org/wiki/Mark_Russinovichhttps://en.wikipedia.org/wiki/Bjarne_Stroustrup:2035+ years later,his Winternals utilities arethe language he created is still in use.
There. Won't say FTFY, but submitted without snark.
OK, maybe a little snark...
I'm old enough to remember C++ being a source code translation into C. It's always been a thin OOP veneer on top of C, and for it's time was pretty good.
The thing is, time was up the moment someone had the idea of a system language that knew about memory safety in its syntax.
I know he pointed out that modern C++ can be pretty safe, but if one were restricted to only that modern subset you'd be wondering why it was called C++ at all, given that you'd have to rewrite a lot of one's code to comply with just that subset.
"Rust, designed by as a hobby by Graydon Hoare"
He must really know how to party -- making a vaguely C-like language but with a compiler that gives errors if you do memory-unsafe or thread-unsafe activities? I mean, I'm a programmer and nerdy and I still find this to be a rather dull hobby 8-)
Anyway.. I really don't think this is a bad idea. I prefer Python but for the types of programming that should be done in C, Rust is fairly C-like but with a ridiculously pedantic compiler that errors out if you write memory-unsafe or thread-unsafe code (there is an "unsafe" keyword, if you have to do some action to talk to existing hardware/software that Rust doesn't like... or if you simply want to do something Rust deems unsafe that you are sure is safe...) It does have facilities for linking with existing C/C++/etc. code too. I'm not a huge fan of Rust any more than I am of C/C++, but I could see Rust being a viable C/C++ replacement in the long term.
I'm personally convinced GC languages are the best solution for applications and tools (including very technical tools, like compilers) where deterministic memory management isn't required.
The basic problem is that C and C++ are Systems Programming Languages, but we're using them as Application Programming Languages. What we need are native code Application Programming Languages, preferably with Garbage Collection or pseudo-pointers / safe-pointers / managed pointers.
It's extremely relevant since C/C++ memory management is literally eating the planet.
We need to get rid of it and we've already done a great job by rewriting many business applications in Java / C# / Go, but we need to go further.
We need to clearly make the distinction between Application Programming Languages and Systems Programming Languages. Don't give me that crap like: "C used to be a Systems Programming Language, but it's now all over the place so it's an Application Programming Language!" It isn't. It's still a Systems Programming Language and we should ban it for application development.
I spend most of my time in GC'd languages these days. It's like pair programming with the dumbest programmer in the office, and assigning them the task of inserting code to deconstruct objects and free their memory... *sigh*
No, that is because of its reputation for being difficult to learn
Comp/Sci types have preferred "difficult" languages forever. And disliked "easy" languages for just as long. "Difficult" plays to their innate sense of superiority, "Easy" languages are for inferior people.
The basic fact is that programming is complicated, because having a computer doing exactly what you want is complicated. It's possible to have a programming language that is more complicated than necessary, and less safe than possible, but it's not possible to have a programming language that is truly simple, unless it wallpapers over issues like memory management that really should be solved by the programmer.
Not biologically, but certainly from an engineering point of view:
https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/
Tony says that index checking should be done at runtime and that it is a very real problem in the world of real FORTRAN programs. What I infer from this is that software engineers in general are not perfect. Humans they are, not gods.
Also, Algol was already much better than C is to the present day. Cheap won out over proper engineering.
Yes, Elon would do exactly that. Single handedly - while using his other hand to tweet about how cool and eficient he is, going against every bit of institutional experience of how one should approach software development to stand a chance of sustainability, let alone success.
In the process he would find out that his development model is unworkable and hastily sell his company, mere days from a financial collapse, to an investor, who in turn would have to rewrite everything from scratch.
Yes, I bet many of us know exactly what would Elon do, as many of us have worked for our respective Elon and were quite happy to part ways with him.
According to Microsoft, about 70 percent of the CVEs it has patched since 2006 are due to memory safety issues. Eliminating those bugs would dramatically improve software security while reducing the cost of vulnerability remediation.
They've been at it since 2006? 2006!? And they STILL haven't squashed the memory bugs? Seriously, do they clean-slate everything every 6 months and start from scratch? Does nobody at Microsoft say "Hey, we wrote code that does exactly this 8 years ago and got most of the bugs worked out. Let's start from there." ? You'd think that at some point, they'd have beaten that 70% down to 5%. Maybe they plan to do that for Windows 2095 on the 100th anniversary of Win95.
They've been at it since 2006? 2006!? And they STILL haven't squashed the memory bugs?
Have you worked on large projects? Fixing all of the memory-use bugs in a large project written in traditional native-code procedural and/or OO languages would take many years even if you're not developing new features.
If only there were ways for companies to implement processes and procedures to help protect their software from developer neglect in the design and implementation phases. It must be something nobody has thought of yet or else Microsoft would have been doing this with their OS developers for decades. It has been over 25 years since desktop computers have been connected to the Internet and every new version of Microsoft Windows is pushed as being the most secure OS or at least the most secure version of Windows.
But maybe it's better to just quickly try to hide the fact they have failed at building a development system which puts security as a priority and point to the shiny new thing which will surely save all of us and be the next greatest toaster.
Microsoft is pretty funny since they've become the platform also-ran.
You discovered their deceptive marketing. Now look at what they claim in the bio virus "vaccine" business.
Secondly, all non trivial C or C++ based systems are chock full of memory bugs. That includes the Linux kernel, PCRE, PNG libraries, PDF readers and hundreds of other widely used packages.
Declaring that C is dead and we should all be using X is a little silly. I guess now I understand what old COBOL programmers felt like when the computing world moved on.
Honestly Rust is a good language and I can't wait to see what a younger generation of programmers will do with it, but I don't see myself writing any serious Rust applications.
Like many programmers in their 40s and 50s I have 30 years of experience with C and I can definitely write much higher quality code in C/C++ than I could in a completely unfamiliar language, even if the language happens to be fundamentally better/safer.
I’ve been a C++ programmer for 25 years and have learned Rust. Yeah it’s not the easiest language to learn but at some point it suddenly “clicks” and development times suddenly decreases a lot. In any case less time is spent debugging, sometimes a lot less time. it only seems complex while learning it, then it becomes plain sailing and a delight to work with.
Apart from memory safety it has a lot of great ergonomics, like the pattern matching, the approach to iterators/adaptors, and the way it handles return values with Return and Option and their many useful member functions is delightful. Then there is the way Mutex<T> and Arc<T> holds their data, etc. etc.
I have no count of the number of code review comments I’ve made in C and in C++ about unhandled return values, potential memory issues and shared data. I’m over it.
Absolutely this. I started my professional career writing C and 8051 assembly code (oh, Keil C51, how you used to torture me,) and had been writing C unprofessionally long before that; I spent many years writing C++ for money, and in general can compete with anyone who wants to shout "get off my lawn" and play who has the longest grey beard - but for my most recent embedded projects (professional and personal) I've switched over to Rust and *could not be happier* about it.
Sure, the language has a learning curve, and there is stuff I don't like about it (async contagion, I'm looking at you,) but that's true of every language. On the other side of the balance, there is just so much more than just memory safety that means I find it simply a far more productive language to code in than C++.
I love C, I loved C++ for a time; Kernighan, Ritchie and Stroustrup will all remain heroes of mine until the day I die, in a pantheon alongside Knuth, Comer and frankly not many else - but the world moves on. The application of multiple layers of lipstick to C++ to try and address its shortcomings over the years has left us with a language that looks more like Conchita Wurst than Audrey Hepburn... It's time to start fresh. And Rust is an excellent choice for that.
Please also look at
WIRTH
HOARE
BAUER
and all the other Algol men. They knew about the need for memory and type safety for decades, if you listen to their speeches. Apparently they were not too much interested in drumming for their ideas, so applied computer science degraded into "free" Unix, instead of the much more robust Algol world.
One of the problems a new language must face is the very large investment in careers and experience that folk have with their other languages. Of course folk are going to be resistant if it means something else is going to eat their lunch or push them out of their comfort zone. Just as some RDBMS folk are about no-sql DBs and other folk feel about other potentially disruptive movements. As a self confessed shit programmer I quite like the ongoing coaching I get from the compiler.
It’s going to be fun watching these comments express these insecurities, as well as the usual gaslighting about Microsoft that has already started.
As someone in my 50s who does a lot of programming and gets paid for it (though I'm not sure I could actually call myself a programmer) I've realised I've hit a wall where there are loads of new technologies I *could* learn, but that I no longer care. I can't be bothered. Just let me write what I know and give me the money. Rust is for the next generation, you know, people in their 40s.
Anonymous in case my boss is reading....
Same here on the SysAdmin side. I don't want to learn the latest and greatest, whether that's "yet another wonderful way to do things" on Windows or how to deal with the new stuff around the systemd cancer. I'm mostly tired of sacrificing brain cells and spare time for things that may or may not be useful in 5+ years. Just let me soldier on, keeping stuff running for another few years, then give me my gold watch and cake and let me go off into the sunset.
As a dev in my very late 40s I'm starting to see why people keep trying to convince me to move into management despite my complete lack of interest or relevant skills... it's you guys with your "I don't want to learn anything new" attitude. Learning something new every day (well ok, most days) is what keeps me young.
Coding keeps me sane, management is the last place they should want me.
Only speaking for myself here, but "learning" is not the issue. I still love to learn new stuff. But now in my mid-50's, I'm tired of the vendor treadmill that's tied to my paycheck. Forced learning because Microsoft or Red Hat or whomever decided to go in a completely different direction for whatever reason and the whole industry has to pivot and follow. I didn't mind in my 30's when I was still eager and mellow and full of energy. But now I'm crusty and often wonder "what the hell good did changing that really do?".
I spent three years in management, and was horrible at it. Not my cup of tea, but the $$$ was good, so I took the promotion. And regretted it. It's not just a different skillset, it's a different mindset. The IT Director really needs to be somewhat of an extroverted "people" person, not a hardcore techie introvert. Now I'm back to adminning, and couldn't be happier (although systemd does make me sad).
And Rust does not address attack vectors that are beyond the scope of sound software design like social engineering.
Of course it doesn't, and so far as is currently known, simplifying arrangements of ancient and old and new shiny words are in overall charge of that/those particular and peculiarly specific and proven troublesome and problematical domain[s].
Words create, command and control and destroy corrupt and perversely oriented worlds, … with the power of hindsight its priceless invaluable remote guide delivering relative impeccable relevant foresight.
And quite whether that continually extraordinarily renders provision of an ideal almost perfect systemic immunity and impunity with an Always All Ways ACTive SuperHyperVision for NEUKlearer HyperRadioProACTivated IT and AI ProgramMING Projects is constantly registering itself for peer review and remote other party otherworldly beta field testing.
AWE*some ..... Advanced Warefare Experimentation .... which may or may not be allied to and aligned with parties outed here harnessing technology to prepare for complex future warfare
Drones and satphones have played a role in Ukraine, but it seems the decisive thing were good old, secret training by Albion and arming them up to the teeth with modern infantry weapons. Playbook Afghanistan 2.0.
A people's infantery, not these SpecOps professional soldiers with long careers. Think of the LONGBOWMAN, just these days with FLIEGERFAUST and PANZERFAUST.
When will you join, Mr Mars ? Takes just a month to learn an ATGM.
When 2 000 000 Russians march west, we need the Landsturm, the Longbowman, whatever you want to call it.
I'm tempted to say something like "OK, Junior"
heh heh heh
The world is fllled with examples on what happens when "the next generation" decides "it is OUR turn now" and they immediately re-invent everything to be THEIR way, and then work through the same kinds of previously solved problems that the old way solved just fine, ones caused by doing it "Their Way".
Yet another gratuitous mention of Arthur C. Clarke's "Superiority"
(if you have never had to create the equivalent of a C structure in either assembly language or FORTRAN, then you may not be capable of appreciating the beauty of programming lingos like C and C++)
FORTRAN was the first language remotely comparable to the imperative languages of today. Then a committee built ALGOL. Two guys at Bell Labs invented C and Unix. In many ways inferior to ALGOL of about the same time. But Unix was "free", so it won over the commercial ALGOL mainframes. Now we discover the real cost of C programs.
This is going to accrue a lot of downvotes but in my experience someone with 30 years of C++ very often means they've been using the same techniques for 25 years and paid very little attention to how things have changed in the language since. Staying up to date is hard and as long as things are working well enough, a lot of us don't really bother as much as we should.
This is a cultural problem with C++ especially, though it also applies to other languages. (Even C has some notable newer features which can help prevent certain classes of errors, but how often do you see identifier-designators used in initialization, for example? That's been in the language for 23 years.)
I've seem some really well-written C++, from people like Stroustrop and Meyers (the Effective C++ books). And some of the C++ I see from professional developers is similarly good, even if I have quibbles about the readability of some of it. But the vast majority of C++ I've seen has been, not to mince words, crap. It's a mess of not-very-good C masquerading as C++ with a handful of C++ features used more or less at random.
A great many C++ developers simply don't seem to know the language well, and don't care about code quality or readability or efficiency.
Part of the problem is that C++ is a huge language. The C99 standard is already rather large at 567 pages, not counting the TCs and Rationale; C++11 is, what, an order of magnitude larger? To be a good C++ programmer I think you either need to specialize in it and put a lot of effort into a really rigorous study, or diligently confine yourself to a manageable subset that you take the time to learn thoroughly. And the former doesn't scale, while the latter doesn't help if you have to work on a team or maintain other people's code.
Afraid I don't share amanfrommars1's enthusiasm for your post (although I won't downvote it).
My experience with "someone with 30 years experience of C++" is that such people generally want to keep up with how the language evolves, and are interested in staying current. Dinosaurs become extinct in software development for much the same reasons as they did in the Jurassic era...because the don't/won't/can't adapt. Sure, there are those who simply want to collect a paycheck and can't be arsed to learn anything new. I have (and continue to) work with some of them. In my experience, they are a rather small minority of the practitioners I work with. YMMV, of course; and if it does, I'm sorry for you.
BTW, I happen to be a "someone with 30 years experience of C++". And there are features of C++23 I can't wait to get my keyboard on.
It's too late for C++ to get its act together and compete with Rust. There's too much cruft in the language and the biggest problem is its backward compatibility. You CAN write memory safe code with the latest version but you can also fall back to 1970's style insecure C programming.
I do dislike Rust for its syntax, especially the => for function return values, which is tedious to type instead of "void" or an actual return type. I would've rather see them adopt the C style like Java and C#.
The biggest bonus Rust brings to the table is stability IMHO. Large C/C++ programs suffer from it and getting all the memory management right is nigh impossible when your application reaches a certain size.
As an avid C programmer, I actually quite like Rust. However it's crates.io language based package manager encourages the fast and sloppy NPM, CPAN, PIP-like development style of dragging in an irresponsible number of dependencies to i.e compare a string.
Also, the way bindings work is that they often need to provide full coverage of a C library. This means that rot due to API breakages is likely. And ironically you end up with more C code acting as binding glue than if you wrote the entire program in C! The fact that C++ is 99% a semi-superset of C is so very valuable for its success in accessing direct C. Rust does not have this. Instead the FFI needs to be used in a similar way to JNI/Python, etc. This is error prone and needs to be done "unsafely".
The Rust language is good, the individual code is good but the projects are too full of technical debt that it is a non-starter for me. I am very interested in using a subset of C or C++ with a borrow checker-like functionality however. Even if just available at debug-time.
Personally I am surprised to hear Mark Russinovich spout any impossible nonsense about "deprecating" languages. For one Rust's dependence on LLVM would kill it.
I'm by no means a fan of crates or other package managers – there's a steady stream of security breaches which ably demonstrates that public software package repositories are toxic, and as you say they encourage programming by including dependencies.
And, yes, the binding mechanism isn't ideal, and LLVM will be an obstacle for some use cases.
However: We're seeing increased regulatory pushback against reckless use of third-party dependencies, thanks to requirements being imposed by large customers such as the US Federal Government. For commercial software development, at least, the SBOM / NIST SSDP / FedRAMP requirements convert some of the externalities of freewheeling use of public packages into direct costs to the vendor.
And the binding mechanism can, in theory, be improved. We saw that happen (to some extent) with Java, for example, where NMI was replaced with JNI.
And non-LLVM Rust implementations are under development. If Rust maintains its popularity, we'll have a usable GCC implementation soon enough.
Agreed, I think many of my current reservations with Rust will be improved. I certainly do hope so anyway.
I think a GCC implementation will really help consolidate Rust. For one a single vendor is never a good idea. It will be interesting to see how it will work though, things like rustup and crates.io will need to become substantially more complex to support both. Actually, the many different C and C++ compiler vendors is probably why we don't have a single "standard" language package manager, instead delegating that role to the operating system's packaging system.
For the FFI stuff, I would really like to see a tiny C compiler bolted onto Rust. Not really to write substantial code in it but perhaps inlining some of the C glue, within unsafe{} sections to reduce the burden of a full fledged binding dependence. I.e if I only need two functions from a C library, I don't want to drag in a full binding with full coverage (including the fragility that comes with that).
> We're seeing increased regulatory pushback against reckless use of third-party dependencies
I do hope this does get resolved. I do dislike having to constantly more and more push back against other developers with their age old argument of "why reinvent the wheel? It may not be round and it is full of punctures but... I'm lazy, careless and have poor work ethic, etc".
C and C++ are very different things by now. C++ stopped being a C super-set a long time ago.
Stroustrup of course gets this right in his reply, he does not mix the languages.
(IMHO C still has its uses, but C++ should be drawn and quartered, then buried at a cross-roads at midnight)
Java is a workhorse in commercial computing. Think of SAP, Android Apps, hundreds of thousands of corporate applications which run massive corporations with dozens of billions of revenue each.
.NET is the little brother of Java for Windows shops.
Memory safety has obvious economic and security advantages. The brittleness of C and C++ is a regression from the days of Algol already. Let's hope they will soon die off.
Oh, and there are also ADA, SPARK ADA, PASCAL and FORTRAN90. Highly reliable projects such as JÄGER90 flight control run on SPARK ADA. It would be a dumb idea to use C++, as they do in the joint stubby wings fighter.
I agree with Stroustrup. Using modern C++ along with static analysis to enforce core guidelines and rules can make C++ completely safe whilst still retaining backwards compatibility.
Static analysis is really no different than using a safety-oriented compiler like the Rust compiler.
It is better to make evolutionary changes as C++ did for C, rather than the revolutionary changes the Rust community is attempting. Any attempts to deprecate C++ will almost certainly fail.
I do really hard disagree here - but the value of Rust only becomes compelling (IMHO) when you are using larger micros with larger code-bases, e.g. a wifi connected ARM or similar.
I also find Rust valuable even in simple cases on MCUs - specifically folks have applied Rust's memory management to IO pins & peripherals, eliminating these classes of errors:
1. Using the same pin simultaneously for two different functions. Rust will make you explicitly give it back or releasing it, else it won't compile. It also sets the pin mux trees automatically inside the compiler.
2. C will happily compile code to target a different peripheral than the one configured in say the graphical tool, or by the pin mux tree, while Rust won't allow that at compile time.
Just my 5C
Start (re-)writing Windows, Word, Azure, et al top to bottom in Rust (or Go, or Erlang, or your next-week's favorite shiny language du jour), and get back to me and the rest of us when you finish, and then we'll talk.
Additional edit:
The Register asked Microsoft whether Russinovich's recommendation is being adopted company-wide. Redmond declined to comment.
Things that make you go "Hmmmm...".
Whilst I agree, at least C++ is close(ish) to being a superset. It is actually closer to "modern" C than old K&R C is to C11.
What really hurts is C/C++/C#. I keep having to instruct HR when they put out job adverts to *not* do that. It is embarrassing ;)
Array Index Error
Use After Free
Invalid Pointer
Pointer to Stack
Invalid Free
Double Free
Unsafe Cast
Multithreaded Race Conditions (probably the worst of all)
Apparently Mr Stroustrup is also a Salesman, when he first claims that memory safety can be achieved, but then says there are no complete checking tools to assure this.
Here is a memory safe C++ variant: http://sappeur.ddnss.de
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
