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: 2) by turgid on Saturday September 24 2022, @05:21PM (13 children)
Long functions are bad because the can be refactored into lots of smaller functions. A function should do one thing and do one thing well. If all of the operations are factored out into their own functions, each can be comprehensively unit tested, put through proper use cases and demonstrated to work correctly. There are some good books on the subject including Clean Code by Robert C. Martin, Refactoring by Martin Fowler, Working Effectively With Legacy Code by Michael C. Feathers and Test-Driven Development by Kent Beck. If you are writing code without unit tests, you are writing "legacy code" by definition.
Design patterns are very interesting. They are an identified set of solutions to common problems plus a (human) language for talking about them. Why re-invent the wheel when there's a design pattern that solves your problem efficiently and correctly?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Insightful) by sgleysti on Saturday September 24 2022, @05:33PM (12 children)
Yeah, I've heard it before. Lots of times. Some of the code I write automates testing with various programmable lab instruments, which often entails doing a long sequence of steps in order. Splitting that up into a ton of tiny functions would make it hard to read. There are helper functions for repeated operations, but not for the top level long list of things the code needs to do in order.
(Score: 2) by turgid on Saturday September 24 2022, @05:45PM (11 children)
What you want is a scripting language.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by sgleysti on Saturday September 24 2022, @05:49PM (10 children)
I definitely do all of this in C++. Static typing, compiling to machine language, and strong support for multithreading are good things.
(Score: 2) by turgid on Saturday September 24 2022, @05:54PM (9 children)
It sounds like you've been a victim of the C++ Inquisition. "You should be writing all your code in C++." What other languages have you looked at? Why does the whole thing need to be compiled to machine language?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by sgleysti on Saturday September 24 2022, @07:20PM (5 children)
I've looked at FORTRAN because I like writing numerical software, but it seems to have poor integration with the OS and poor library support for some of the things that I do. I still might pick it up at some point in the future. I've used Python here and there, especially sympy for computing partial derivatives for optimization routines and matplotlib to make nice graphs, but I wouldn't use it for anything that needs multithreading, responsiveness, or speed due to the interpreter hit. I'm pretty good with MATLAB and GNU Octave, but again, I mostly use those for simple graphing of data, playing around with or prototyping numerical code, or some quick calculations.
C++ is amazing. It's fast, has lots of great features (you don't need to use them if you don't want), good OS integration, good library support (in my case Rohde & Schwarz's VISA library for talking to test instruments, C libraries for various data acquisition devices, and so on), lots of existing open source code (the Eigen Linear Algebra package is the one I use most, but there's so much), strong support for multithreading, and some great compilers. The STL comes baked in and is of very high quality. And you can use lots of C libraries and stuff.
Rust looks really promising due to the memory safety stuff. If C++ didn't already meet all of my needs and perhaps more, I might take the time to learn Rust.
Other people can write their software in whatever language suits their fancy. I'm not telling you or anyone else what to do. I am saying that I love C++ for the reasons above. Although, my favorite is still programming 8-bit PIC microcontrollers in assembly.
(Score: 2) by turgid on Sunday September 25 2022, @04:31PM (4 children)
FORTRAN is from another era, when programs were entered on punched cards and paper tape, and the terminal was a teletype with paper and an ink ribbon. Arrays in FORTRAN are in column major order. The syntax of the language is atrocious. It's totally ad-hoc and inconsistent. It does have some advantages over the C family of languages in terms of ability to optimise certain types of code because it doesn't have pointers and therefore pointer aliasing is not a thing. Back in the 50s, 60s, 70s and even the 80s a lot of numerical code was written in FORTRAN. In those days people didn't believe in unit tests. Combined with the horrendous nature of the language, human civillisation's numerical scientific code is enshrined in mysterious, unmaintainable gobbledygook and no one can rewrite it because they can't figure out what it does. The people who wrote it are long gone.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by sgleysti on Sunday September 25 2022, @06:17PM (1 child)
FORTRAN is still actively maintained and still used to write numerical code.
(Score: 2) by turgid on Sunday September 25 2022, @06:44PM
Indeed it is.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 0) by Anonymous Coward on Sunday September 25 2022, @10:21PM (1 child)
I've typed many thousands of lines of FORTRAN and never used a punch card or teletype printer. I'm not sure what you find so horrendous about the language as I never found the syntax to be atrocious. It was wonderful to not have all these semicolons all over the place. Everyone it seems who started programming in the 90s or later have the oddest notions about FORTRAN, not just irrational, but almost defensive angry, even if they've never had to program in it at all. I've never understood it. I've had more than one Millennial insist that you have to use GOTOs in FORTRAN, which is why it is such a "horrible" language (even if one idiotically and blindly follows Dijkstra regarding the GOTO statement, for the record I've never needed to use one). I mean, how do you even have a conversation with someone with notions like that? That's "not even wrong."
And are you really blaming FORTRAN for peoole not writing unit tests?
(Score: 2) by hendrikboom on Monday September 26 2022, @12:51AM
When did Fortran acquire IF-THEN-ELSE and the like? Was it in the 80's? the 90'S?
(Score: 3, Insightful) by sgleysti on Saturday September 24 2022, @07:24PM (2 children)
Forgot to answer this one...
Have you ever written a routine that, even with the best available algorithms, maxes out a modern parallel processor for a non-trivial amount of time? Or that has throughput or latency requirements that require high performance code? Having done those things, I find interpreted languages so incredibly wasteful. Even when something would still work well enough in an interpreted language, I like the software that I use to be responsive. And if I'm writing it for myself, one great way to have a good chance at responsive software is to write it in some language that compiles to machine code.
(Score: 2) by turgid on Sunday September 25 2022, @09:08AM (1 child)
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.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by sgleysti on Sunday September 25 2022, @06:30PM
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.