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.

[1]: https://en.wikipedia.org/wiki/Sysinternals

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?

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.

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.

The C/C++ people hate it when you call it C/C++.

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

I envy CTOs with street cred on hn

[deleted by user]

For systems programming, use whatever the Linux kernel uses. For everything else, there is javascript.

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++?

Umm, no thanks.

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++.

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...

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.

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.

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.

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.

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://youtu.be/GQ1EDqsA1yk

https://techcommunity.microsoft.com/t5/windows-blog-archive/...

I'm paying attention to him.

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.

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.

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.

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.

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’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.

The management ecochamber will push rust until their faces turn blue.

The truth is we don't need rust, either you are making a server and the 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.

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.

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.

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.

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.

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.