Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated | Bjarne Stroustrup: Nope.

[Delicieuxz]

Microsoft Azure's Chief Technology Officer doesn't have a favourable opinion of industry cornerstone languages C and C++, and would like to see more modern, allegedly secure languages, like Rust, replace them. C++ creator, Bjarne Stoustrup, 

 

Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated

Quote

Mark Russinovich, Microsoft’s Azure CTO, says that C and C++ should not be used for new projects.

 

“It’s time to halt starting any new projects in C/C++ and use Rust for those scenarios where a non-GC language is required. For the sake of security and reliability, the industry should declare those languages as deprecated,” he said on Twitter, expressing a personal opinion rather than a fresh Microsoft policy.

 

Russinovich’s remarks are notable because Microsoft’s core products, such as Windows, Office and SQL Server, are largely written in C and C++. So too is Linux, which also has widespread use on the Azure cloud platform. That said, it will soon be possible to write parts of the Linux kernel in Rust, judging by reports from the recent open source summit and an email from Linux creator to journalist Steven Vaughan-Nichols in which he said: “Unless something odd happens, it [Rust] will make it into 6.1.”

 

In Rust We Trust: Microsoft Azure CTO shuns C and C++

Quote

The Register asked Bjarne Stroustrup, creator of C++, to comment. We'll update this story when we hear back.

 

Updated to add

 

Stroustrup got back to us, defending the language he invented.

 

"It is not unusual for people – especially executives – to become enamored with new and shiny things that promise to make their lives easier," he told us.

 

"Also, backing something new is far more exciting than addressing the known problems of older and well-known tools. Unfortunately, it usually takes many years and major efforts for new languages to match mature languages in their wide application areas. Enthusiasts rarely see that and tend to be rather one-sided in their comments."

 

"Safety is obviously critically important in many contexts, so I have worked on increasing safety in C++ for years," the language's creator continued.

 

"We can now achieve guaranteed perfect type and memory safety in ISO C++. That is, every object is used according to the type it was defined with. That implies that we eliminate uses of dangling pointers, catch range errors, and eliminate data races. Note that every 'safe' language, including Rust, has loopholes allowing unsafe code."

... [his comments continue]

 

I'm not a programmer, so I don't really know what either person is talking about, when discussing potential security vulnerabilities with either language. However, I am trying to learn C++, and hope to eventually be able to make my own games, for fun. And so, I'm interested to hear what people who are knowledgeable of the languages think about this debate or idea that one language might have limitations or a perceivable, practical shelf-life date coming on the horizon. I'm drawn to C++ because the games I love were made with it, and I'd enjoy making 90's-style games in the language the ones I played were made in. I also would like to make games that start by launching a DOS-style prompt that users need to enter commands into, to get the game to run, or to make the game play sound. If it can't be done with 640kb of RAM, is it even worth doing?

[Bombastinator]

I’m not either.  I hung out with a lot of people that were though.  So I will share my probably over simplified and fractured understanding of this one.  As I understand it, The very concept that c and c++ are the same thing or more than even vaguely near the same is ridiculous.  
 

I used to have a friend that was on the C standards committee.  The way I heard it, and saw it unfold, was C+ (which turned into c++) was one of those ridiculous things like c#. An attempt by Microsoft to take a perfectly good language and crush it with BS.  Why isn’t it C++ and C#? Those actually have more in common.  Also where is objective C in this?  
 

This smells to high heaven.  “Yeah, let’s get rid of the stuff my company doesn’t own or can no longer control, and replace it with stuff that it does.  C# was always a mess.  If this is a guy who had anything to do with that I consider him biased.  C# was originally supposed to be and marketed as compatible with C but like a lot of things microsoft it never quite was.  Personally I suspect C++ is unkillable.  It’s a massive hairball, but it’s like cobol.  There’s just too much stuff written in it.  Like autohotkey a giant mess, but it will just go galumphing along forever.  It’s mostly just really big though. It’s not the impacted wtf of autohotkey that evolved basically at random.

 

The way I understand it is c++ is c+ (the thing that Microsoft made in its first attempt to take over C) that got added to so heavily it was basically no longer the same thing anymore. It has bunches of specialized commands created for specific problems.  It’s a bit like rock&roll.  Ever changing. C is emphatically not that way. 
 

This reminds me a bit of right wing attempts to destroy USPS in favor of fed ex and UPS because they’re private for profit companies that lobby. FedEx and UPS were given massive advantages over USPS but they still couldn’t kill it because aside from the initial advantages they had (fed ex invented the hub system.  I forget what UPS did) they basically have nothing else. So they did really really well for a few years but they didn’t do a lot more real innovating, and they’re just fundamentally less efficient.

 

This also reminds me a bit of PASCAL.  Pascal was never more than a teaching language and while Turing complete it was woefully under developed for major uses.  It was the new hotness way back when though and the original 68k toaster macs had their OS written in it.  Boy was that a mess down the line.  Apple had to basically abandon it. It was like writing an OS in python, which was the new hotness for a while too.  Then it got superseded by ruby, then Ruby on Rails.  You want to evangelize whatever is the new hotness now let’s see where they are in 10 years.  Most of the time it’s  “what?”.  
This comment likely deserves a good deal of “Um.. actually..” which I’m totally OK with. Like I said I’m not a programmer.

Edited September 26, 2022 by Bombastinator

[LAwLz]

47 minutes ago, Bombastinator said:

As I understand it, The very concept that c and c++ are the same thing or more than even vaguely near the same is ridiculous.  

I don't think anyone is saying that it is, and this news topic isn't about that.

I don't think it is ridiculous to say that C and C++ are similar though. C++ is an extension of C. They share A LOT of things with one another.

 

 

50 minutes ago, Bombastinator said:

I used to have a friend that was on the C standards committee.  The way I heard it, and saw it unfold, was C+ (which turned into c++) was one of those ridiculous things like c#. An attempt by Microsoft to take a perfectly good language and crush it with BS.  Why isn’t it C++ and C#? Those actually have more in common.  Also where is objective C in this?  

Two things:

1) C+ was never a thing. Maybe you're thinking of "C with Classes"? 

2) Neither C, "C with Classes" nor C++ was developed by Microsoft.

 

The reason why objective C isn't mentioned in this news article is because it is not relevant to the things being discussed. Barely anyone is thinking "should I use C++ or Objective C for this new project?", especially not on the Azure team.

 

 

 

1 hour ago, Bombastinator said:

This smells to high heaven.  “Yeah, let’s get rid of the stuff my company doesn’t own or can no longer control, and replace it with stuff that it does.  C# was always a mess.  If this is a guy who had anything to do with that I consider him biased.  C# was originally supposed to be and marketed as compatible with C but like a lot of things microsoft it never quite was.  Personally I suspect C++ is unkillable.  It’s a massive hairball, but it’s like cobol.  There’s just too much stuff written in it.  Like autohotkey a giant mess, but it will just go galumphing along forever.  It’s mostly just really big though. It’s not the impacted wtf of autohotkey that evolved basically at random.

Neither C++ nor Rust is owned or controlled by Microsoft. This is not them saying "we need to move to something we control". I am not sure why you keep bringing up C# either, because this person is not telling people to move to C#. 

You can open the sources and search for C# if you want. You won't find a single mention of it, except in the devclass.com page where it is just listed among other languages like Python and JavaScript. 

 

Mark is saying new projects should use Rust instead of C or C++. 

Rust started life as a project from a Mozilla employee, and after some layoffs as Mozilla is now headed by the Rust Foundation, a non-profit organization whose team consist of full time employees like Rebecac Rumbul (previously worked for mySociety) and a board of directors from multiple large companies like AWS, Google, Huawei, Meta, Mozilla, Microsoft, etc. Only one from each company however.

 

Rust is not a Microsoft product. Microsoft does not control it in any way. In fact, the Linux kernel has started using Rust as well for some things. I believe they have an NVMe driver written in Rust for example.

[05032-Mendicant-Bias]

I use a lot C and C++, NODE.JS and javascript. I'm learning python.

I haven't used rust so far.

4 hours ago, Delicieuxz said:

"It is not unusual for people – especially executives – to become enamored with new and shiny things that promise to make their lives easier," 

This is on point. Before getting into python, it was this magical thing where everything was easy and fast. Getting into it, you need a lot of stack overflow to prepare statements in the way the interpreter does the thing you want it to do, there is lot of ambiguity, especially with third party semi-standard libraries like numpy.

 

E.g. because python doesn't have the concept of type, you cannot overload arguments. You can, the interpreter is more than happy about it, but it will do the wrong thing, and you need to implement by hand conditional behaviour based on argument type: if argument is an int, use it as index, if touple, build a matrix.

There are is lots of syntactic sugar and boilerplate, just like there is in C++, but for different reasons in different places.

 

I haven't used rust, but I would expect rust has places where it shines, and places where is not the best tool for the job.

Python is good to do datascience and charts with notebook.

C++ is good at doing high performance code.

 

46 minutes ago, LAwLz said:

I don't think it is ridiculous to say that C and C++ are similar though. C++ is an extension of C.

I used to think that, but it's more misleading than helpful thinking this way. C++ is it's own thing that uses C like syntax.

e.g. I used to predeclare structures and union, and that lead to compiling error in C++. The C++ compiler has this beautiful architecture with stack unroll on constructor and destructors that allows to safely handle memory. It's very powerful and effective. It takes forever to build and link because of just how much work the compiler has to do with the automatyc type resolution and templating.

[leadeater]

6 hours ago, Delicieuxz said:

 I also would like to make games that start by launching a DOS-style prompt that users need to enter commands into, to get the game to run, or to make the game play sound. If it can't be done with 640kb of RAM, is it even worth doing?

Good luck with that, the Windows thread management wrapper around the process when you run it probably uses more than that now days lol (no I don't actually know )

[Franck]

17 minutes ago, leadeater said:

Good luck with that, the Windows thread management wrapper around the process when you run it probably uses more than that now days lol (no I don't actually know )

With C it's possible by using minimalistic package. When you write some code for embed device that is the nice thing about C (C++, C#). You can specify what you want to bring with your code when compiling. You can target the 520-640kb range like Dos 3.0 and up was fond off.

[leadeater]

5 minutes ago, Franck said:

With C it's possible by using minimalistic package. When you write some code for embed device that is the nice thing about C (C++, C#). You can specify what you want to bring with your code when compiling. You can target the 520-640kb range like Dos 3.0 and up was fond off.

Yea the process itself can use that little, I just mean Windows itself because it has to manage all the running processes and simply running something up this small probably adds on more than 640kb just to manage it 

 

It's probably not actually true but I wouldn't be surprised if it is.

[Quackers101]

I guess a lot of newer languages does use a lot of simplifications to make some of the process easier or faster.

to functions that might be good to use and maybe updated security and updated language, but isn't easier to fall for traps too when using something like that just as you can fall for traps in more complicated or harder to deal with language.

 

like lets not forget millions of servers with the Log4j event

https://www.pcmag.com/how-to/what-is-the-log4j-exploit-and-what-can-you-do-to-stay-safe

[Sauron]

6 hours ago, Delicieuxz said:

I'm not a programmer, so I don't really know what either person is talking about, when discussing potential security vulnerabilities with either language.

They're talking about safety, not security. One of Rust's main selling points is memory safety, meaning that the language is built to prevent issues that arise from bad memory management. Modern C++ also has a lot of features that were added to address these problems, however they still depend on the programmer's will to use them and knowledge that they even exist - whereas in Rust you don't really get a choice.

 

While I like Rust and the philosophy behind it I'm not sure it's ready to completely replace C++ just yet, and C still offers performance benefits over both in some niche use cases. Deprecating C++ seems premature to me. Plus there are so many existing projects that use it which should still be able to benefit from modern features.

[leadeater]

7 minutes ago, Quackers101 said:

I guess a lot of newer languages does use a lot of simplifications to make some of the process easier or faster.

Faster maybe, slower (execution) quite often. Whenever I have to read in very large files within a PowerShell script I don't use the PowerShell command syntax for it I use the supported ability to call a .Net JIT compiled piece of code and read the file that way because it's legit like 1000 times faster.

 

But I'm a sucker for making it simple and then fixing things like performance later if required, I just want the darn thing to function.

[LAwLz]

14 minutes ago, Sauron said:

While I like Rust and the philosophy behind it I'm not sure it's ready to completely replace C++ just yet, and C still offers performance benefits over both in some niche use cases. Deprecating C++ seems premature to me. Plus there are so many existing projects that use it which should still be able to benefit from modern features.

Please note that Mark specifically said Rust should be used over C or C++ for new projects that can't be written in a GC-language.

I don't think anybody is saying C and C++ should be abandoned completely. But if you are going to write a brand new program that you want to be high performant, Rust is probably the language you should choose over C or C++.

[Sauron]

1 minute ago, LAwLz said:

Please note that Mark specifically said Rust should be used over C or C++ for new projects that can't be written in a GC-language.

 

Yes I'm aware, still I don't think we're quite there yet.

2 minutes ago, LAwLz said:

But if you are going to write a brand new program that you want to be high performant, Rust is probably the language you should choose over C or C++.

There are still good reasons to use C over Rust for very high performance applications and C++ has a huge library advantage. When parity is reached on these fronts then it will make more sense to exclude them a priori.

[LAwLz]

40 minutes ago, Sauron said:

There are still good reasons to use C over Rust for very high performance applications

Source?

Rust performs roughly the same in all benchmarks I have seen. It wins some, and loses some. Usually it depends on how the code is written rather than the language.

Remember, Rust is a compiled language that doesn't use a GC nor reference counting. It's not like for example Python or Java.

 

40 minutes ago, Sauron said:

and C++ has a huge library advantage. When parity is reached on these fronts then it will make more sense to exclude them a priori.

Except integrating third party libraries into a C++ project is a pain in the ass so most people don't even bother. Rust makes it far easier to do.

For those who don't know, integrating a library in C++ requires you to build it from source. Doesn't sound too bad, but since a lot of C++ projects are very complex, you might have to set up an entirely independent build system for each and every third party library, and each one may require their own compiler flags/version, other dependencies, maybe a specific file system structure, etc.

 

A lot of C++ developers simply don't even bother using third party libraries because it is such a headache as soon as you use anything other than a handful of basic ones. It is often times easier to just rewrite the function yourself and do it using your own build environment rather than try and get someone else's code to compile for you.

 

Meanwhile, in Rust, you just run cargo build and it just works.

Hell, you can even use C libraries in Rust if you want. Rust natively allows you to link to C libraries. 

[Sauron]

14 minutes ago, LAwLz said:

Source?

There are multiple benchmarks you can find but here's one comparing the same driver program implemented in both C and Rust

https://github.com/ixy-languages/ixy-languages/blob/master/Rust-vs-C-performance.md

 

Rust is almost as fast as C - almost. To get the absolute highest speed achievable in Rust you need to turn off the safety features it's desirable for in the first place and sometimes even resort to inline assembly, making the transition kind of pointless.

18 minutes ago, LAwLz said:

Except integrating third party libraries into a C++ project is a pain in the ass so most people don't even bother. Rust makes it far easier to do.

I agree, but there's no substitute for stuff like Eigen3 in Rust just yet. For many use cases it's probably no issue but again, until there's full parity it's a tough sell to just ignore C++ entirely as an option for your projects.

21 minutes ago, LAwLz said:

Hell, you can even use C libraries in Rust if you want. Rust natively allows you to link to C libraries.

Yeah but that kind of defeats the purpose, don't you think? This is arguably the opposite of deprecating C.

[igormp]

31 minutes ago, LAwLz said:

Meanwhile, in Rust, you just run cargo build and it just works.

 

While I gotta give that cargo is amazing, there's still the problem that most libraries, specially the ones meant for embedded, aren't available in the rust-world, so you can't just download it. Heck, no-std is a recent thing, and they still haven't made it possible for their runtime to just not panic on any errors (which is not acceptable for bare metal stuff).

 

So, you either get a C/Cpp lib and wrap it around the FFI, which will end up as a mess of {unsafe} and spaghetti code, rewrite that stuff in rust, or just continue using C/C++.

34 minutes ago, LAwLz said:

Hell, you can even use C libraries in Rust if you want. Rust natively allows you to link to C libraries.

For anything moderately complex it's a pain, talking from experience here.

 

Another thing that still hasn't been solved is how Rust compile times take sooooooooo freaking long, it's bonkers and worse than an awfully-templated C++ code.

[LAwLz]

9 minutes ago, Sauron said:

There are multiple benchmarks you can find but here's one comparing the same driver program implemented in both C and Rust

https://github.com/ixy-languages/ixy-languages/blob/master/Rust-vs-C-performance.md

 

Rust is almost as fast as C - almost. To get the absolute highest speed achievable in Rust you need to turn off the safety features it's desirable for in the first place and sometimes even resort to inline assembly, making the transition kind of pointless.

But like I said, C wins some and Rust wins some. We are talking single digit percentage performance differences and it can swing in either way depending on exactly what is being done. 

I don't think performance is a valid argument for C because it does not consistently perform better. You could use the exact same argument for Rust by that logic.

 

Also worth mentioning that the Rust code in that benchmark outperformed the C code when the safety features were turned off. So if you value some small percentage speed increase so much, Rust with safety turned off is still better than C, according to your own source.

 

 

16 minutes ago, Sauron said:

I agree, but there's no substitute for stuff like Eigen3 in Rust just yet. For many use cases it's probably no issue but again, until there's full parity it's a tough sell to just ignore C++ entirely as an option for your projects.

If you need some specific library that doesn't have an equivalence yet (a lot of them do, nalgebra does a lot of the stuff Eigen3 does, or maybe ndarray, depending on what you want) then you could always use the C library in Rust for the time being.

 

 

18 minutes ago, Sauron said:

Yeah but that kind of defeats the purpose, don't you think? This is arguably the opposite of deprecating C.

I don't think it defeats the purpose.

Mixing and matching languages in your project isn't a big deal. Why not draw advantage of the Rust language in the areas where it makes sense, and use for example a particular C library if you need to where it makes sense?

Using C in places where Rust would be safer and better just because you happen to use one C library in one place doesn't make much sense to me. Just write the program in Rust and link the C library if necessary.

[Sauron]

3 minutes ago, LAwLz said:

I don't think it defeats the purpose.

Mixing and matching languages in your project isn't a big deal.

It's not that it's a problem to include different languages, it's that the whole discussion is about completely substituting C and C++ with Rust because of the safety features. If you just write C code in your Rust projects you're both still using C and giving up Rust's safety for those sections of code. You're making the case for not abandoning C and C++ entirely just yet. I'm absolutely not saying you shouldn't use Rust if you can, just that deprecating C and C++ right now would be premature.

[Bombastinator]

5 hours ago, LAwLz said:

I don't think anyone is saying that it is, and this news topic isn't about that.

I don't think it is ridiculous to say that C and C++ are similar though. C++ is an extension of C. They share A LOT of things with one another.

 

 

Two things:

1) C+ was never a thing. Maybe you're thinking of "C with Classes"? 

2) Neither C, "C with Classes" nor C++ was developed by Microsoft.

 

The reason why objective C isn't mentioned in this news article is because it is not relevant to the things being discussed. Barely anyone is thinking "should I use C++ or Objective C for this new project?", especially not on the Azure team.

 

 

 

Neither C++ nor Rust is owned or controlled by Microsoft. This is not them saying "we need to move to something we control". I am not sure why you keep bringing up C# either, because this person is not telling people to move to C#. 

You can open the sources and search for C# if you want. You won't find a single mention of it, except in the devclass.com page where it is just listed among other languages like Python and JavaScript. 

 

Mark is saying new projects should use Rust instead of C or C++. 

Rust started life as a project from a Mozilla employee, and after some layoffs as Mozilla is now headed by the Rust Foundation, a non-profit organization whose team consist of full time employees like Rebecac Rumbul (previously worked for mySociety) and a board of directors from multiple large companies like AWS, Google, Huawei, Meta, Mozilla, Microsoft, etc. Only one from each company however.

 

Rust is not a Microsoft product. Microsoft does not control it in any way. In fact, the Linux kernel has started using Rust as well for some things. I believe they have an NVMe driver written in Rust for example.

So you’re saying that c+ never existed?  This does not jibe with my memory of things.  Also why would it be called “++” if there was never a “+”?

It IS possible that c+ had little to do with c++ though despite the name.  My assumption that c++ was more similar to c+ than C was just that.

 

You apparently read a different or at least much extended thing than I did.  I only read the quote, which doesn’t really talk about rust.

 

thankyou btw.  I strongly suspected that there was something wrong with my understanding of this and you did point out at least one glaring problem.

[Sauron]

4 minutes ago, Bombastinator said:

So you’re saying that c+ never existed?  This does not jibe with my memory of things.  Also why would it be called “++” if there was never a “+”?

Because "++" in C syntax is shorthand for incrementing a number by 1. It's just a way to indicate that it's originally an expansion of C. There was never a "C+" as far as I'm aware.

[ToboRobot]

Russinovich wants to be able to enable lesser skilled programmers (increase labour force) and Stroustrup seems of the opinion that we still need better programmers, not just better tools.

[igormp]

1 minute ago, ToboRobot said:

Russinovich wants to be able to enable lesser skilled programmers (increase labour force) and Stroustrup seems of the opinion that we still need better programmers, not just better tools.

Huh, I don't think that's the case, since rust has a way harder learning curve than C++ and you fight against the compiler a LOT while learning it.

[ToboRobot]

2 minutes ago, igormp said:

Huh, I don't think that's the case, since rust has a way harder learning curve than C++ and you fight against the compiler a LOT while learning it.

C/C++ have decades of education and refinement compared to Rust.  I think people are talking about the future. 

In 10-20 years, will it be easier to write good code in C or Rust, and I think Russinovich expects there to be more people with Rust skills to employ, and that it will be cheaper that high level C programmers.

[Bombastinator]

5 minutes ago, Sauron said:

Because "++" in C syntax is shorthand for incrementing a number by 1. It's just a way to indicate that it's originally an expansion of C. There was never a "C+" as far as I'm aware.

I do remember one rather distinctly.  It may have been a short lived BS thing that was mostly marketing and didn’t really get used though.  One of those “new hotnesses” except it was even less hot than even I thought.

[Sauron]

14 minutes ago, Bombastinator said:

I do remember one rather distinctly.  It may have been a short lived BS thing that was mostly marketing and didn’t really get used though.  One of those “new hotnesses” except it was even less hot than even I thought.

LMAO, turns out it DID exist and it was the programming language for TempleOS  later renamed to "HolyC"

 

but still it was made after C++ and it wasn't a middle step between C and C++

[LAwLz]

1 hour ago, ToboRobot said:

Russinovich wants to be able to enable lesser skilled programmers (increase labour force) and Stroustrup seems of the opinion that we still need better programmers, not just better tools.

Or maybe he wants memory safe programs, because even really skilled developers makes mistakes?

In 2020 alone, Microsoft had 173 security issues related to memory overflows. Most if not all of those could have been prevented if they used Rust.

 

It's like saying we invented seatbelts because we wanted to allow worse drivers on the roads. No, we invented them because accidents do happen, even the best drivers can be in an accident. And when someone messes up, we want to minimize the damage it causes.