Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Friday September 23 2022, @11:35PM   Printer-friendly
from the leaks-are-for-kids dept.

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


Original Submission

 
This discussion was created by janrinok (52) for logged-in users only, but now has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by turgid on Sunday September 25 2022, @09:08AM (1 child)

    by turgid (4318) Subscriber Badge on Sunday September 25 2022, @09:08AM (#1273535) Journal

    Yes, I know, I've seen project proposals where people were going to do something in Python and then spend $100k on the hardware just to get it to run fast enough without any understanding of how Python works underneath (most of the hardware being wasted). My question about scripting languages was for your use case where you are automating tests using lab equipment. Unless you have some fancy real time requirements, you could use a scripting language for that and make your development and test cycle much shorter. It would also make the test cases more easily maintainable by other people. There would be a smaller learning curve.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by sgleysti on Sunday September 25 2022, @06:30PM

    by sgleysti (56) Subscriber Badge on Sunday September 25 2022, @06:30PM (#1273593)

    My question about scripting languages was for your use case where you are automating tests using lab equipment. Unless you have some fancy real time requirements, you could use a scripting language for that and make your development and test cycle much shorter. It would also make the test cases more easily maintainable by other people. There would be a smaller learning curve.

    None of those things are my goals. To provide some context, I am personally writing code to automate tests for myself. The software is not the end goal; the test results are the end goal. I don't spend all my time learning or writing software—it is a means to an end. We have an automated test group at work, but they're to busy to help me with my stuff. They're more focused on system level testing of entire products and do their work in LabView, which by the looks of it would drive me crazy. The company doesn't have the budget to give me a LabView license anyway, and I don't have the time to train up on it.

    I already happened to know C++, and it does work well for this purpose in the sense that I can get the tests up and running and working reliably in a reasonable amount of time. I can link to solid, professionally developed libraries for instrument control (Rohde & Schwarz VISA). I can link to libraries for other data acquisition equipment (usually supplied by the manufacturer). I understand the code and can fix it if something goes wrong. It's performant. One time, I had a bench DMM sampling at max rate in one thread while I was reading 20 event driven digital channels in another thread, eventually outputting everything to a VCD file. That was before the automated test people came around. I found so many bugs in the firmware written by our software team with that setup. Most of them having to do with misunderstanding or missing details in the supplied specifications, or coding themselves into such a corner with their pretty frameworks that implementing needed features required a ton of refactoring.

    I don't know python well enough to write solid, functioning code on the first try reliably and would have to take the time to get there. Since C++ works very well for me, there's no incentive to learn something that runs slower and where I'd be relying on some library downloaded with pip that I wouldn't feel I could trust and wouldn't know the internals of.

    And no, I do not write unit tests for this code.