SoylentNews is people
SoylentNews
Memory safe programming languages are on the rise. Here's how developers should respond:
Developers across government and industry should commit to using memory safe languages for new products and tools, and identify the most critical libraries and packages to shift to memory safe languages, according to a study from Consumer Reports.
The US nonprofit, which is known for testing consumer products, asked what steps can be taken to help usher in "memory safe" languages, like Rust, over options such as C and C++. Consumer Reports said it wanted to address "industry-wide threats that cannot be solved through user behavior or even consumer choice" and it identified "memory unsafety" as one such issue.
The report, Future of Memory Safety, looks at range of issues, including challenges in building memory safe language adoption within universities, levels of distrust for memory safe languages, introducing memory safe languages to code bases written in other languages, and also incentives and public accountability.
During the past two years, more and more projects have started gradually adopting Rust for codebases written in C and C++ to make code more memory safe. Among them are initiatives from Meta, Google's Android Open Source Project, the C++-dominated Chromium project (sort of), and the Linux kernel.
In 2019, Microsoft revealed that 70% of security bugs it had fixed during the past 12 years were memory safety issues. The figure was high because Windows was written mostly in C and C++. Since then, the National Security Agency (NSA) has recommended developers make a strategic shift away from C++ in favor C#, Java, Ruby, Rust, and Swift.
The shift towards memory safe languages -- most notably, but not only, to Rust -- has even prompted the creator of C++, Bjarne Stroustrup and his peers, to devise a plan for the "Safety of C++". Developers like C++ for its performance and it still dominates embedded systems. C++ is still way more widely used than Rust, but both are popular languages for systems programming.
[...] The report highlights that computer science professors have a "golden opportunity here to explain the dangers" and could, for example, increase the weight of memory safety mistakes in assessing grades. But it adds that teaching parts of some courses in Rust could add "inessential complexity" and that there's a perception Rust is harder to learn, while C seems a safe bet for employability in future for many students.
[...] To overcome programmers' belief that memory safe languages are more difficult, someone could explain that these languages "force programmers to think through important concepts that ultimately improve the safety and performance of their code," the report notes.
Are you or your employer using or considering memory safe languages, and if so what is your opinion of them in your particular sphere?
(Score: 2) by JoeMerchant on Friday January 27 2023, @03:35PM (2 children)
Point being: if Rust won't compile clever tricks, then you can't employ those clever tricks to save power when using Rust (whereas you could employ said tricks in C).
C has had 30+ years of clever tricks created for it, I'm sure a great many of them don't port easily to Rust, some may.
For "Hello World" I'm sure Rust is plenty efficient. It's in the use cases that the compiler writers haven't thought of yet that the clever tricks come into play.
Personally, the lazy deep copy Qt has been using, forever, to save memory usage on everything from QString to QPixmap and larger containers... that has always made me a little queasy, particularly while doing a debugger stack trace through it. I've learned to just accept that it works, and it seems to, but once every 10 years or so it bites me like this with me making an assumption that something is always copied, when in fact it's only copied 9,999 times out of 10,000. and in that 0.01% case you still get lucky and avoid crashes sometimes by pure dumb luck.
🌻🌻 [google.com]
(Score: 2) by RamiK on Friday January 27 2023, @06:06PM (1 child)
There's nothing in C/C++ that can't be transliterated into Rust/TinyGo with zero performance costs. The resulting code won't be the prettiest thing to look at and won't have safety advantage by itself, but it's the first step to a translation-rewrite where you'll be able to remove undiscovered memory allocation bugs without even knowing you did simply by replacing manual allocations with automatic ones while dissecting for bottlenecks. And to be clear, people ARE working on it: https://github.com/immunant/c2rust [github.com]
And of course, once you have a clean safe code base and a whole stack of safe code top-to-bottom, you can start redesigning things with less sandboxing (like the Android APIs example I've mentioned last time the topic came up...).
Anyhow, this translation-rewrites are a few developer generation churns away from becoming common practice. That is, much like how assembly-to-C and FORTRAN-to-c rewrites only really got into gear after the workflow smoothed out and the developers got used to the workflow, it will probably take about a decade before will start seeing people saying "instead of paying a few guys to go over our code with a fine comb to find bugs we don't even know about, lets just stick the code in a translator and have our devs spend a couple of weekends to clean it up so all those hidden off-by-ones and glitches will mostly sort themselves out automagically".
compiling...
(Score: 4, Insightful) by JoeMerchant on Friday January 27 2023, @07:58PM
I did a bit of Fortran to C++, and a bit more Matlab to C++ (and, yes, they tried the automatic translator, then they hired me at 6 figures...) The real thing they both needed was somebody who could put a decent UI on the glop that the statisticians and PhD researchers were doing.
>those hidden off-by-ones
We had a team of three doing some of that Matlab to C++ translation, I had a junior guy in there who liked doing circular buffers and I told him: take the time to put together a verified working circular buffer template and use that every single time, don't hand code them, the human brain just isn't wired to get them right on the first try. Of course he didn't listen. Of course over half of his circular buffer "custom" implementations had off by 1 bugs in them.
🌻🌻 [google.com]