It's time to halt starting any new projects in C/C++
You could say that Mark Russinovich is a hacker's hacker, the foremost Windows hacker, and a reverse engineering wizard. It was he who discovered and blew the whistle on the Sony rootkit scandal, for example, after finding and reverse engineering it on his machine.
https://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootk...
He extensively reverse engineered and documented "Windows Internals" details before joining Microsoft (and before being "encouraged" to change the name of his business to Sysinternals).
His writings and talks on "The case of..." are master classes on reverse engineering.
https://techcommunity.microsoft.com/t5/windows-blog-archive/...
I'm paying attention to him.
Calling him the Azure CTO is strictly accurate, but HN readers probably know Mark Russinovich better as one of the primary developers of sysinternals[1].
I bring that up to highlight the weight of his opinion: Russinovich is legendary in terms of his systems programming contributions.
I tried Rust about five years ago and I had trouble expressing cyclic data structures because there is no clear "owner" in a cyclic data structure. The "safe" solution recommended by the rustaceans was to use integers as references to the data in a vec or hashmap. I was rather put off by this: Instead of juggling pointers I was juggling integers. It made the code harder to debug and find logic errors. At least when I was troubleshooting C I could rely on the debugger to break on a bad pointer, but finding where an integer became "bad" was more time consuming.
The borrow checker worked fine when all I needed to do was pass data up and down the callstack, but anything beyond that was difficult or impossible to express. Has the borrow checker become smarter since then? At the time I was very put off.
Blanket statements like this just show that people don’t understand why people stuck with a language.
I worked in C/C++ for a long time, though it’s been a while now. I just went to look at whether Rust had any bindings for MPI. It does - rsmpi. But they’re not fully implemented, and only support a restricted subset of MPI implementations which are pretty much the latest versions. Some others might work, but it is not explicitly tested against them. Without that, there’s a whole class of distributed applications that you’d be ill advised to write in Rust using that library, because it’s such a fundamentally core library for distributed applications, which needs to be compiled differently and with specific versions to handle the specialist interconnects on HPC systems. If you only support the latest versions, your code is not very portable to other machines.
Someone else downthread: "young developers can pick up Rust quite fast, and that makes it vastly easier than trying to find talented C/C++ developers."
I hope so. I have a hypothesis that the big-O for language success is "How easily can new programmers learn it?" Nothing else matter. JavaScript was slow, but everyone learned it, so it got fast. Python still had bad tooling, but everyone learned it, so it got better. And C got popular in the first place cause it was easier than assembly.
I wanna ask my managers if we could try hiring Rust devs. I don't like hiring people fresh out of college, but I can't manifest more money to hire experienced C++ devs. If the pool of good-enough-Rust devs is growing faster, and maybe already bigger than the good-enough-C++ pool, why am we interviewing people who don't even know what they don't know about C++?
I'm just a programmer who's been doing this for 20 years. I don't have the credentials of Mark, who is a legend. But I fully agree with him. There will be specific exceptions, but if you have the choice between Rust and C++ you would be making a big mistake to not choose Rust. The language is simpler, cleaner, safer, and more enjoyable to work with. The build tools are far more pleasant. The IDE experience is comparable. The hiring market is way better for Rust because it's not mainstream. Programmers currently using Rust are superior to programmers using C++, statistically speaking. There's a vast difference between individuals, but with only that one data point you can tell quite a lot. People learn C++ in college. People learn Rust because they love their craft. I stopped using C++ after I learned Rust. I still use Go sometimes, when appropriate, and I use other languages in my day job. I have a lot of experience in C++, much more than with Rust. The borrow checker still drives me mad. I've worked in over twenty languages over the years. Languages are tools, try to be impartial and pick the best tool for the job. Your personal tastes don't matter unless it's your personal project.
There are new programs being written daily in COBOL and Fortran, and I'm fairly certain that I see new PL/I floating around occasionally.
C and C++ aren't going anywhere anytime soon. Love them, hate them, want to burn them with fire, they're here for a long, long time.
Leaving that aside, I was still hitting Rust "oh look the developer of this crate on which the entire universe depends still assumes that everything is x86, and one of five operating systems" issues as recently as late 2021. Rusties of the world: your language might be ready to take up the mantle of C- it's you and your ecosystem that I question.
If Rusties want Rust to displace C... simplify your dependency chains. Get a build system that's easily workable without an Internet connection and recent TLS support. Make it easy for beginners to build out Rust infrastructure for OpenVMS on Itanium, Solaris on SPARC, z/OS, MorphOS, GNU/Hurd, and a 20-year-old budget PDA running a custom OS on an SH4 CPU. Make it feasible to get Rust everywhere that C currently is... then we'll discuss getting rid of C. Until then it's just wind.
Unless he means that Rust should be used on projects where the Rust compiler is available for all relevant platforms and C and C++ can be used otherwise, I disagree.
In fact, until LLVM is replaced, C++ will probably be the language of choice for new languages. Even `rustc` requires a C++ bootstrap for that purpose.
There are also other important C++ and C libraries that will continue to mean C and C++ may be better choices than Rust in certain cases.
And don't get me started on embedded.
Also, that doesn't even matter when the purpose is a hobby project (such as mine) where the programmer has no interest in Rust (such as me).
I like how Trevor Jim put it [1] better:
> If you decide to write your project in C/C++ you must have a plan for handling the inevitable memory corruption in advance. Anything else is malpractice.
This is possible to do. I've released a non-trivial program that has had no known memory bugs ever since 1.0 on 2018-10-26. It is written in C. And I challenge anyone to find one in any release since then. You might find one, but I think it will be tough.
In other words, it's possible to put C and C++ on the same footing as Rust when it comes to memory bugs; after all, even Rust is not perfect there.
Yes, it takes more effort. A lot more effort. For my hobby projects, that works fine because I'd rather work in C with the extra effort than in Rust.
Oh, and it's possible to make C as good as Rust: I've got macros to do automatic bounds checking. I've got RAII and stack traces. I've got structured concurrency, which will give the same capabilities as the Rust borrow checker if you adjust your coding style. And all this in portable C11.
So no, Rust is not the end-all be-all of languages. Sorry.
Rant about absolutist opinion over.
But seriously, use Rust if it's available for your target platforms, and you have no other preference.
[1]: http://trevorjim.com/using-an-unsafe-language-is-a-design-fl...
This guy is the bonafide hero behind sysinternals.
Mark, if you read this, please start with porting Sysmon to Rust. A Microsoft supported doc on how to use Rust when developing using the DDK would be amazing as well.
Sysmon on Linux uses ebpf, would be a selling point if it was also written in Rust.
Seems like kind of a crazy thing to say. The first thing to note, is that we should obviously be free to write software like games and other utilities in whatever language we want, especially if they’re not connected to the internet. Second, why exactly are we demonizing people now? Suddenly declaring a language deprecated not only doesn’t actually make any sense, but also seems like a great way to influence people’s personal opinions about others. I can tell you from experience that sentiments like this breed hostility in the workplace. And finally, this is pretty short-sighted, considering the supply chain attack is clearly the attack of the coming age.
I think this title could be misinterpreted.
There is a difference between Mark Russinovich saying this, as a personal opinion, and Mark Russinovich, Azure CTO, saying this as a company policy/directive.
This tweet does not indicate that it's from him in his official capacity as Azure CTO.
As much as I like rust, I feel the statement is a bit premature.
Rust has only one real compiler and no independent language standard.
Rust is also the only alternative that is really being discussed most places. For an idea as major as "deprecate C/C++" you really want a couple solid alternatives. Rust is not perfect for everything, and so its easy to pick on the weaknesses and say "that's why we're sticking with C/C++".
I guess Ada or D are viable alternatives, too, and maybe need more attention. But the tweet only mentions rust.
I wish technical people would stop pretending that choice of programming language isn't just largely very much a personal choice and then occasionally based on whatever else the ecosystem has to offer.
Yeah, most people doing scientific computing might use Python, but then you have whole groups of people who are used to something else and would plainly prefer not to use a language for completely personal reasons.
Like, hey maybe the syntax sucks.
I’ll controversially go a step further and say we need to even begin requiring this via regulation for certain applications, at least for those that involve the personal or financial data of customers. From working with security at a large tech company, it’s abundantly clear that C/C++ should not ever be used for processing sensitive information (it’s fine to keep around for high performance computing or processing non-sensitive data). There are just too many people involved in making codebase changes and too many potential errors to be made. Not every company has the resources to devote to an in-house static analysis team.
We have all sorts of regulation in other industries to protect consumers, and with so much of our economic infrastructure dependent on the security and integrity of information processing, it’s bizarre to me that we’re still using programming languages with severe deficiencies for these purposes.
Will there be performance hits, cost hits, and inefficiencies introduced by requiring safer languages? Of course. But I see that as vastly preferable to the dangerous state of cybersecurity at almost all companies.
I get that it makes sense at his level, but my impression is that mistakes in the business logic are both more common and more financially painful for the company than the memory safety issues that Rust solves when compared to C++.
Unsafe binary? Run it in docker.
Crashes? Run two and monit.
RAM leak? Restart with cron.
Now I'm not saying that these are good solutions, but they are good enough so that plenty of companies get away just fine with running buggy c++ software in production. So in my opinion, the biggest improvements come from better abstractions and good libraries. And c++ still has the lead there.
The C/C++ people hate it when you call it C/C++.
Inside Azure there’s an over reliance to C#, and the older versions of it to boot! So one team in charge of making .NET run faster and better, while the other one drags on using decade old versions
Then for “speed” there’s weird mashups of C++ and C# that are just littered with terrible internal build tools that harken back to a nice 2010s and the idea of:
“Idk it builds in my machine just fine”
As far as Rust goes, it’s as plentiful as F# projects (so not existing).
But that’s just what my close friend says at least.
I'm waiting for Rust to support both static and dynamical link equally well. static link produces binaries too large for my embedded boards when stdlib is needed. dynamic link looks like a second class citizen to me in Rust. Is there some hope?
How much support does Microsoft give to the Rust Foundation (financial and otherwise)?
Does Visual Studio (not VS Code) support Rust programming?
Are there plans for an official Rust SDK for Azure? https://github.com/Azure/azure-sdk-for-rust
Casey Muratori's opinion on Rust: https://twitter.com/cmuratori/status/1367627549816152064?lan...
Speaking of Microsoft, it's time to halt starting any new projects in Windows and use Linux for those scenarios where an OS kernel is required. For the sake of security and reliability. the industry should declare that OS as deprecated.
Getting kind of tired of these idea that people should apologize for writing in C or C++. I'd much rather have people build useful stuff in whatever languages they're comfortable with, than having them not doing so. Security isn't everything in every application. The usefulness of unsafe code continues to vastly outweigh the costs of the associated CVEs.
Compare Stepanov's brilliant design of the STL to Rust's current reworking of their 'binary search api'. https://github.com/rust-lang/libs-team/issues/81
Maybe 'memory safety' isn't the most important thing in this world. To me, writing software that does useful things in the simplest and most correct way is what matters. I get the feeling it's harder to understand my program's correctness with Rust (I mean algorithmic correctness). The C++ standard library has time and space complexity for every algorithm. I'm not seeing that's the case with Rust (correct me if I'm wrong).
I've just trying to remember all the times i've heard this in relation to other languages replacing C/C++. I'd say java and C# are definitely in this category, but also python, go and probably swift too.
So I can now add rust to this list.
It's also interesting to see this as a tweet, avoiding any worry about the nuance of the problem domain, the experience of the developers, or what problems they encounter. Sure, rust is safer than C++, but is this important to the project you work on? What sort of problems do you encounter? Would rust help? What problems would it introduce?
Anyhow, 'rust is the new C++'. I wonder what the calling cry will be in 5 years time.
The volume of existing C, C++, Objective-C, and C# code is phenomenal. Even if this strategy is generally adopted there will continue to be lots of this legacy code for many years to come. In particular there will continue to be such legacy code right up until 2038 at least.
Ada offers security and simplicity and is already part of GCC but also has llvm now. Linux kernel drivers have also been demonstrated.
Perhaps it would be healthier for Rust to have competition?
https://www.linux.com/audience/developers/hacking-the-linux-...
https://github.com/alkhimey/Ada_Kernel_Module_Framework
Nvidia also chose Spark; a built in subset of Ada as being more cost effective for secure code than C++.
Assembly is also supported by Ada and I found it far easier to add than with C even.
C interface support is also excellent.
I still use Lazarus/Pascal, not as clumsy or random as pointer math, an elegant language, for a more civilized age.
Wirth was wise to do everything possible to discourage pointer use, and make it obvious. Hejlsberg and company gave Pascal a worthy library and IDE. Then the language florished under the Turbo Pascal, and later Delphi banner.
But then Hejlsberg turned to the dark side, and joined with the MicroSith. They bought forth Sith.NET, Sith# and all other manner of evil.
I like memory safety as much as the next guy but an unelaborated opinion tweet is not hacker news.
Can you even use Rust for Windows GUI programming? Is it a practical choice at all for interfaces?
I think this is a silly idea. There are still loads of questions surrounding Rust. Especially about it's practicality... There are articles denigrating the likes of the trait and async systems on HN almost every day. And even ignoring that argument, any language is viable, so long as it can be used to build what you want to build.
I am still ok with plain and simple C for cross-CPU code, for now. c++ is lost in grotesque and absurd complexity (that's why gcc move to c++ was one of the biggest mistake in software, ever).
I am one of the guys who would like RISC-V to be successful, then "port" everything to RISC-V assembly, without excessive usage of the macro pre-processor, then forget about compilers.
Linus T. (more likely the guys pulling the strings of the linux fondation financing) green lighted rust in the kernel, I bet this is some horrible gcc extended rust, not core and simple rust (hope they have the decency to compile linux rust code with the rust compiler written in rust). A long time ago, I had a look at rust syntax and was disappointed by the strings hardcoded in the syntax and all that "package" management system hardcoded in the syntax, but most syntax looked like a re-arranged C. Were they able to keep it that simple? (no grotesque objet orientation or those horrible templates or garbage collector or hardcoded weird and expansive memory allocation model).
The pb is C syntax is too already too complex. I wonder if rust suffers from the same issue, hope they "fixed" C: only sized types, no integer promotion, no implicit cast (except for void*), compile-time/runtime casts (without that horrible c++ syntax), only 1 loop keyword, no enum/typedef/_generic/etc, etc.
This is a stupid "hot take", no matter the stature of the person who said it. They may have a point, but they aren't making much of an argument with a single tweet.
There are C programs I wrote in 1982 that still compile and run (and do still do what they were intended to do.) There are rust programs from 5 years ago that don't compile. I have rust programs from 2 years ago that compile but silently fail because semantics of the language have changed.
Before we say C must die, let's think of the modern marvel of reverse compatibility.
But sure, C++ should die. Having to look at several files to figure out how a statement works is annoying.
He is probably right but then that doesn’t mean it will happen. Having worked in Ada 25 years ago, and made the argument (which largely fell on deaf ears for reasons that most of us this old understand), I think his statement is less controvesial than you might imagine. These changes take a long time, but I’m already encouraged by what I’m seeing, especially with companies like Cloudflare adopting a rust proxy in place of nginx.
I just wanted to say how much I love that this community values Mark as a "hacker" above being the CTO of Azure, and then goes on to lists his technical hacking credits.
Hacking is still alive even if we all need paychecks.
Then Azure should probably get some Rust SDKs: https://azure.microsoft.com/en-us/downloads/
Completely agree. And this isn't even controversial. The controversy is about whether to make rewrites, including it in the Linux Kernel and so forth.
But for greenfield projects in systems languages? First of all, that niche is tiny. There may be sub-niches where availability of some specialist library makes it harder to use Rust than C++, but I'd argue that if some library or ecosystem is that important, your project isn't completely green field. An Unreal game isn't a greenfield project even if I start now because the Engine is a massive piece of C++ you have to live with.
For anything this niche of "green field enough", I'd go with Rust even if I had a whole team consisting to 100% of experienced C++ developers. And I wouldn't even sweat the decision.
How good is rust at using existing C/C++ libraries? There’s so many of them for very useful low-level functionality, especially when programming against the Win32 API (which is written in C/C++ itself). Could I write a Windows kernel driver in rust?
I also can’t ignore the fact that Mozilla has been in serious decline as an organization in recent years. I worry about rust’s long-term trajectory as their support of the language wanes. It’s one of the reasons I feel so positive about the future of go, as they have a lot of dedicated people on it from google (an organization that in all likelihood won’t be going anywhere anytime soon).
I don’t feel that his opinion is all-encompassing. If Rust is being used in the name of security and reliability, then C/C++ should remain king of game development, where those two aren’t as important.
I'm hopeful for other alternatives like Zig too
It's also time to have a spec & alternative free implementation for Rust. Multiple compilers and standard library implementations for C is the reason why it's so ubiquitous in the embedded space and where Rust can do a lot of positive impact.
As of now, Rust does not have a spec: https://users.rust-lang.org/t/where-is-the-rust-language-spe...
I can see how somebody familiar with windows internals would like to burn it all down asap.
It would seem to me that as long at C++ is the primary language to write for a GPU, it will be a necessary language for new projects for a long time.
I would have complied if he said D lang.
Tried Rust, did not like it that much, compared to D.
It's a good thing I got my latest one started before this was announced!
All kidding aside, as others have pointed out this is coming from someone with tremendous credibility and it is worth giving some consideration. I have a lot of respect for Rust although I've only toyed with it for personal projects. The compiler provides very helpful messages (vast majority of the time), but even so, for complex applications it can still be very difficult to reason about.
As has already been mentioned, it doesn't seem to be anywhere near prime time for GUI applications (such as those built with Qt, Gtk, Win32, etc.). I don't think it's fair to say that ALL GUI apps should be built with a managed language.
Like with go, one of the nice things is that there's just one provider of the compiler. At least you don't have to contend with different levels of support and different compiler options.
I envy CTOs with street cred on hn
To save you a click to Twitter's hyper slow website, Russinovich recommends to start new projects in Rust instead.
C sits at a sweet spot of performance vs. expressiveness vs. portability whose Pareto-optimality has withstood a half-century test of time. It’s not going anywhere.
The case for replacing C++ is a lot stronger but I don’t see game engines, for instance, switching to Rust (or using garbage collection) any time soon.
> For the sake of security and reliability.
I just read a few C++ vs Rust comparisons online yesterday and didn't see anything about a significant difference in security or reliability. Mind you the articles weren't very technical.
How is Rust so much more secure and reliable than *modern* C++?
Is he actually doing it? Making a plan and a policy to replace the bone marrow of MS with Rust? Or is this just a pie in the sky tweet? I don't know what Mark is like as a CTO, so I really don't know what to expect here.
I don’t disagree overall. We can do a lot better these days but Rust just doesn’t do it for me.
That language makes a train take a dirt road. It’s big, complex, and I have to believe “not what we are actually looking for”.
Haskell promised all kinds of safety too and has back doors to hide “unsafety” that are basically “game over”. Rust doesn’t seem to do much better in this regard. Maybe I’ve not written enough of it. (I’ve written far more Haskell)
How bad is GC really? Has Go shown it to be manageable and not an issue yet?
Seriously spending all my time in C and C++ due to the nature of my job, I can’t say I’m convinced we’d ever start using Rust.
undefined
This sort of reminds me of the 1994 essay "Why you should not use Tcl" by Richard Stallman. Then, if memory serves me, we all switched to scheme and lived happily ever after.
I highly doubt that it's easy to hire rust developers.
Maybe it's possible to hire c++ dev and make them work on a rust project?
Anyhow, is there a qt equivalent for rust? Can rust really compete with c++?
I've read rust code and I'm sorry but it seems like the steep learning curve is just not worth it, even if the benefits are big.
I still believe rust fills the same niche of ada, meaning tight requirements. Most c++ projects don't care that much. It's cheaper to test things or rewrite than betting on a new difficult language.
It’s jarring to see how somebody’s fame in a specific domain makes them believe they can dictate what other companies and entire industries can use.
Read his internals book - much appreciated back when I was doing Windows programming. Used his tools - very nice while I was still using Windows.
But I never looked to Mark Russinovich or any Microsoft guys to advice on what programming language to use. What’s the point of making such an arrogant proclamation?
Lumping C and C++ together implies much about the use of the language - "modern" C++ features go out of their way to avoid memory unsafe and bug-prone operations (avoiding raw pointer arithmetic, no manual new/delete memory management etc). Comparing Rust against the overlapping subset of "C" and "C++" is rather disingenuous. It's like writing /everything/ in Rust in an unsafe block and avoiding all the tools that actually make it a more productive language.
I'd agree today you totally shouldn't be starting new projects in C-with-classes style C++, and take advantage of all the newer tools available in newer versions instead. Sure, Rust and similar may have even better tools to help the programmer, but talking about raw productivity, especially in shorter projects, learning a new language and all the fumbling and mistakes and anti-patterns that can hurt the result, as well as longer-term maintainability, may be worth consideration. Especially, as even if the core project is brand new code, the library ecosystem it's working in may still be more mature around other languages.
It totally makes sense to me relegating C and older-style C++ to systems where it's really the only choice (platforms with older/poor tooling, places where the resulting code requires more massaging than usual like resource-limited embedded situations and the developer is already skilled in this with their current toolchain, other situations that no doubt some people will find etc etc.)
Meh. I agree with the sentiment, but in practice, I’m not sure we’re there yet. Maybe once Rust has a more robust standard library and less language-level churn we’ll be there.
If you’re writing something safety-critical, sure, use a memory-safe language like Rust/Go/etc. Otherwise, I think C++ is still plenty viable.
When people use "C/C++" as a single language I usually know right away don't know much about C++. The distance between C and modern idiomatic C++ is many times larger than the distance between C++ and Rust. C++ looks like an ancient juvenile dialect of Rust compared to C and C++ looking almost nothing alike. You can write shit C++ that looks like C and breaks like C or you can write good C++ instead and end up with less (almost none in practice) memory problems also. This discussion comes up multiple times a week and almost never do the people having it actually know what they are talking about. I am aware this person is a big shot that has done great things, but it's still impossible he has seen actually good C++ written in the last 5 years. Not because it doesn't have memory bugs, because they are much harder to make. Language landscapes change and old languages die and new languages get popular, but it seems this whole thing is based on a giant strawman (that C++ is the same as C). It's very frustrating.
Great. When I thought I just became expert level in C++, this? Hmm.. fine time to learn Rust.
New C++ projects will continue to be started every day for a loooooong time. There are millions of C++ programmers out there and most of them have zero interest in switching to another language.
What should I use for stm8 on Linux then? The only thing available is assembler and C.
Another one lost to the cult.
Right, because I'm going to take advice on writing programs that need to not have a GC from someone who has never written any program that needs to not have a GC.
There are a couple of industries were C++ is king and I seriously doubt Rust will be adopted en masse for the foreseeable future: game dev and audio dev.
undefined
Uh-huh. Meanwhile we're still launching new projects in Cobol, a language that's been "dead" for the past 40 years!
According to Joel Spolski, of Microsoft Excel fame, he left Microsoft because of the company’s policy of encouraging the developer community to waste time and energy chasing new software technologies rather than shipping great software.
In other words, Msft has a long history of suppressing competition by steering the industry away from doing things that could threaten Msft’s dominance: like moving your company from the C++ language you’ve mastered to a new modern language you don’t know well.
In C++, there is Move semantic. If we use "Move semantic" in C++ code, could it match the memory safety of the Rust?
Herb Sutter, who also works for Microsoft and has dedicated his entire life to advancing C++, may be really sad right now.
Would Rust be able to replace C++ in HFT?
Mark is not the subject. He is speaking of Rust and memory safety. I agree with him in general, that if a project requires C/c++ kind of capabilities then better to use Rust. But, if one doesn’t require Rust then I think one must avoid it by all means, because it’s such an investment into such a huge learning curve and such deep levels of complexity and mental burden.
undefined
If only IBM can get Rust working on AIX..... we may even start using it. Rust is an able C/C++ replacement. Even Linus, who's picky about what goes into the kernel tree, is allowing/supporting it. It really shouldn't be a burden to pick up for anyone who's done C/C++, IMHO.
I stopped doing new projects in C++ years ago, and now I only code in Pascal
agreed, zig only from now on
I wonder what triggered this tweet? Does Azure use a lot of C/C++?
undefined
Fortran is still in use so im not worried that i use c++
Umm, no thanks.
He has a vested interest in renting hardware, so resource efficiency is opposite to his goals.
It would not surprise me he praises Python =)
Why is Rust supposed to be good?
Very reasonable suggestion.
No, I’m going to write everything in C.
undefined
undefined
undefined
undefined
undefined
> "C/C++"
Opinion discarded. Sorry.
are the rumors true, that much of Azure was really bolted-together Ubuntu things.. has that changed, aside from the reality of web-facing service pages growing by the thousands themselves...
Surprised he didn't get ratio'ed.
I'm glad I don't have a Twitter account. I'd have spent the whole day arguing with stupid replies (both for AND against OP's point).
I believe sysinternal tool are handy, but it not more useful than core utilities on Linux. Even that doesn’t not give him to ask everyone not to use certain languages.
Obviously geek’s rant is still a rant.
LOL... Two of the most successful Windows tools I've seen in a long time are both written primarily in C/C++. Winget and Windows Terminal. Please let me know when Microsoft has a major Rust-win, because so far they haven't.
The Azure CTO knows as much about C++ as to easily confuse it with C. Anybody who say C/C++ is not aware that C++ is vastly different from C and it can't be combined into a single "language" like this. Mark Russinovich puts his ignorance on full display here.
Imagine how much impact we could have if we used all the effort gong to develop Rust and port everything over to Rust to instead just improve the wrinkles that exist in C++.
This makes more sense to me than trying to bring memory safety to C++. C is mostly frozen, do that with C++ and deprecate both. 50 years from now they will still be around but compatibility will be good due to the freeze. Everything new will be much safer and maintainable.
This is a very long term strategy but it makes sense viewed that way.
The management ecochamber will push rust until their faces turn blue.
Until they rewrite mrustc in rust everyone using rust is one dependency up.
The truth is we don't need rust, either you are making a server and then Java is the language to use.
On the client where rust has a good chance to compete with C we're looking at electricity cost problems and then C is an easy choice.
You need to compile things to be productive.
Has he ever heard of kernels or device drivers? Probably not.
For systems programming, use whatever the Linux kernel uses. For everything else, there is javascript.