SoylentNews is people
SoylentNews
Arthur T Knackerbracket has processed the following story:
Mark Russinovich, the chief technology office (CTO) of Microsoft Azure, says developers should avoid using C or C++ programming languages in new projects and instead use Rust because of security and reliability concerns.
Rust, which hit version 1.0 in 2020 and was born at Mozilla, is now being used within the Android Open Source Project (AOSP), at Meta, at Amazon Web Services, at Microsoft for parts of Windows and Azure, in the Linux kernel, and in many other places.
Engineers value its "memory safety guarantees", which reduce the need to manually manage a program's memory and, in turn, cut the risk of memory-related security flaws burdening big projects written in "memory unsafe" C or C++, which includes Chrome, Android, the Linux kernel, and Windows.
Microsoft drove home this point in 2019 after revealing 70% of its patches in the past 12 years were fixes for memory safety bugs due largely to Windows being written mostly in C and C++. Google's Chrome team weighed in with its own findings in 2020, revealing that 70% of all serious security bugs in the Chrome codebase were memory management and safety bugs. It's written mostly in C++.
"Unless something odd happens, it [Rust] will make it into 6.1," wrote Torvalds, seemingly ending a long-running debate over Rust becoming a second language to C for the Linux kernel.
The Azure CTO's only qualifier about using Rust is that it was preferable over C and C+ for new projects that require a non-garbage-collected (GC) language. GC engines handle memory management. Google's Go is a garbage-collection language, while the Rust project promotes that Rust is not. AWS engineers like Rust over Go because of the efficiencies it offers without GC.
"Speaking of languages, 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," Russinovich wrote.
Rust is a promising replacement for C and C++, particularly for systems-level programming, infrastructure projects, embedded software development, and more – but not everywhere and not in all projects.
[...] Rust shouldn't be viewed as a silver bullet for all the bad habits developers practice when coding in C or C++.
Bob Rudis, a cybersecurity researcher for GreyNoise Intelligence, who was formerly with Rapid7, noted developers can carry across the same bad security habits to Rust.
"As others have said, you can write "safely" in C or C++, but it's much harder, no matter what dialect you use than it is in Rust. Mind you, you can still foul up security in Rust, but it does avoid a lot of old memory problems."
(Score: 4, Insightful) by maxwell demon on Saturday September 24 2022, @05:41AM (2 children)
There are new iterations of C and C++ constantly. Also, unlike hardware, languages usually get new capabilities through libraries. A new language means loss of all the libraries that haven't yet been ported. To mitigate that problem, many languages include ways to call C code.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 3, Insightful) by sgleysti on Saturday September 24 2022, @04:45PM
And FORTRAN code.
(Score: 3, Informative) by turgid on Saturday September 24 2022, @05:44PM
There's another subtlety, though. On a Unix/Linux system, the Application Binary Interface, the way programs call each other, is defined by the output of the C compiler. Because Unix was written in C (the first portable OS written in a high-level language) the way C calls functions is the way you call the OS and hence other libraries on the system. Any language that can generate code that speaks this ABI is therefore compatible. By default, C++ does not. It has all sorts of hackery underneath. In general, interpreted languages do not either, for obvious reasons. Pascal and its family of languages do not by default (they put arguments on the stack in the opposite order).
On a Unix or Linux, the convention across the OS is for libraries to use the C ABI. That's what comes out of the compiler used to compile the system, after all. The problem comes when you have a load of libraries written in C++ (which is quite common). Because of C++'s weirdness, you won't be calling those libraries from any other program not written in C++ and not only that, having been compiled with the same compiler. That is, unless the programmers have provided an interface to the library using the C calling convention. That's a load more work in C++. It means wrapping each API call in an 'extern "C {}' declaration with a C function call...
C++ was supposed to take over the world. Fortunately it didn't.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].