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: 3, Insightful) by VLM on Saturday September 24 2022, @03:20PM (2 children)
The problem is the concept of turing complete languages. There's nothing you can write in lang A that can't eventually be translated into lang B, in the sense they're all in the same complexity class.
The way it has rolled out for decades is the bad coders write bad code on old languages because thats all they had. "Hey look, the bad coders all use gwbasic / perl / C, so if we use the new shiny Python / C++ / whatever then we won't have bad programmers, so we'll have good code". Then the bad coders arrive, code quality in that language goes to shit, rinse and repeat with yet another new language, apparently Rust.
This is a good site:
https://www.rust-lang.org/learn [rust-lang.org]
But bad programmers will never learn from it anyway, and will just F up the code some other way. At least you know what to expect with C and C++, LOL.
You know for a fact that bad programmers will start to use Rust and they'll implement some kind of dynamic storage system for strings that uses an array of 8-bit bytes, and WTF why not implement null terminated strings in those data-buffer arrays, and a crap tier homemade function to allocate ranges of that array for certain tasks, and WTF if you're going to implement null terminated strings in your array of bulk data why not implement a function probably named strcpy that copies strings until it sees the null termination, like what could possibly go wrong, obviously Rust will save us all in this situation. Why would a programmer implement a dynamic memory heap of his own instead of using "Safe" library? Well, thats so complicated and if they were good programmers they wouldn't be the problem anyway blah blah blah.
The other problem is best explained as the Scala experience where Scala never prevented bad coders from making type mistakes, it just made everyone define all the types as Any because the lower skill programmers prevent the use of types. (It has been something like 7, 8 years since I last used Scala but IIRC "any" type short circuited all the Scala type safety stuff and you can't fire everyone who can only use type Any in scala code for all type annotations and "ship it yesterday" mentality will always apply so if it compiles and runs with everything set to type Any then thats whats gonna ship)
(Score: 2) by sgleysti on Saturday September 24 2022, @04:42PM (1 child)
I really, really hope this is not correct:
There's no language fix for bad coders, as you get across. I do think languages with new features can make it a lot more practical for reasonably competent coders to maintain or increase productive output while introducing fewer bugs into the code. Rust seems to have some legitimate technological innovations along these lines in the area of memory safety. Personally, at my last job, I wrote C++ code basically like "C with STL containers", and I avoided using C pointers. Valgrind always came back saying "no memory leaks possible". I probably would have fucked up something if I wrote programs with identical functionality in C. I probably would have learned more about coding also.
All of that said, my favorite programming language is Assembly for 8-bit PIC microcontrollers (and related Holtek microcontrollers). But I mostly use that for hobby projects and little fixture circuits to help run tests of electronics hardware at work.
(Score: 2) by RamiK on Saturday September 24 2022, @07:12PM
That's not quite true. Purely functional programming language make it really hard to write shit code. Not impossible. But hard enough to deter bad coders. Also, a language like Dala [arxiv.org] that goes at glitches through capabilities pretty much prevents sloppy coding due to forcing the developer to think through what they're doing.
Anyhow, the point is, if you take away the imperative conveniences out, bad coders will actively avoid using your language.
p.s. There's also something to be said about data flow languages here but it's not as easy to argue.
compiling...