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: 4, Insightful) by hendrikboom on Thursday January 26 2023, @06:42PM (1 child)
I use Scheme these days, which descends from the oldest of the memory-safe languages, Lisp 1.5.
(Score: 4, Touché) by quietus on Friday January 27 2023, @10:13AM
(Score: 0) by Anonymous Coward on Thursday January 26 2023, @06:50PM (2 children)
It's the Rise of Rust.
(Score: 2, Touché) by Anonymous Coward on Thursday January 26 2023, @08:28PM (1 child)
or the resurrection of Ada
(Score: 2) by turgid on Friday January 27 2023, @07:46AM
Ada is a great language. When it came out, compilers for it were very expensive. To call a compiler an "Ada compiler" it had to be properly validated against the official test suite, which cost a lot of money to do. However, it did mean that you could trust the output of the compiler, which was a big deal 40 years ago. In those days, compilers were notoriously buggy.
Compilers for Pascal and then C were much cheaper so they became much more popular languages. Pascal had quite a head start over C, but then C and C++ took over, and here we are.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 5, Interesting) by hendrikboom on Thursday January 26 2023, @06:53PM (34 children)
There's a widespread practice to write libraries in C, because most other languages have foreign function interfaces allowing them to call code written in C. A library written in C can this easily be called from a variety of other languages using C calling conventions.
A library written in garbage-collected languages isn't so easily callable, even from another garbage-collected language. Thus each of these memory-safe garbage-collected languages forms an isolated island, difficult to use together with other such languages.
This is a hindrance to being able to write widely-used program libraries in a memory-safe language. The bridges between languages are traps for any attempt to write memory-safe code.
We need a standard garbage-collector interface mechanism which could be used to bridge the gape between the garbage collectors in different languages.
Perhaps a component of this could be a uniform mechanism for describing the low-level data structures used in a language to the garbage collector so that it can garbage-collect uniformly across language boundaries.
-- hendrik
(Score: 1, Insightful) by Anonymous Coward on Thursday January 26 2023, @08:12PM (5 children)
(Classic) Visual Basic had no (major) problems calling .NET code.
I don't think GC's are the main issue here. Calling conventions, yes, but GC, no...
(Score: 0) by Anonymous Coward on Thursday January 26 2023, @08:30PM (4 children)
I think that is, at least in part, because there was really only one language involved: .NET intermediate language. C#, VB .NET, "managed" C++ were all just preprocessors to the .NET intermediate language.
As soon as you leave the Microsoft bubble, you lose that commonality.
(Score: 3, Interesting) by Anonymous Coward on Thursday January 26 2023, @09:10PM (3 children)
Not in the case of the referenced classic VB. That was created when .net wasn't even a glimmer in the milkman's eye - we're talking pre-1997, whereas .net is from the early 00's. It could (and still can, it just won't die) talk to .net all day long.
Granted, all of these are within the microsoft ecosystem but one is still a GC'ed (set of) languages, and the other (VB) isn't.
(Score: 4, Informative) by DannyB on Thursday January 26 2023, @10:29PM (2 children)
LibreOffice and the old OpenOffice.org code could be called, on Windows, from any language, like VB that could call COM objects. For example Visual FoxPro.
I wrote code in Visual FoxPro that could do a CreateObject() call on a registered type[1] and then create other objects and open a document. Say a "Draw" document. I could then create lines and shapes on this document all by remote control from Visual FoxPro. I think I even have old examples I could dig out.
But I could just as easily create other objects in other registered DLLs in other programs (like Excel, Word, etc) using CreateObject() and then go crazy from there -- using Visual FoxPro of VB. (Not VB.NET, but old fashioned pre-.NET VB)
This is just because of the design of COM on Windows. Not any foreign function interfaces.
Now here is a weird one. I once built a DLL using Visual FoxPro. (Yes VFP can create DLLs as well as EXEs) I declared a number of VFP classes as exported from the DLL (I don't remember the precise details, but I still have the source code). Then from a Java program, actually a web server on Apache Tomcat, I used a third party Java library, I think it was called "Jacob" which allowed Java to access Microsoft COM. So from a Java code, as a servlet on Tomcat, I could invoke an object and call methods on it, from a DLL written in Visual FoxPro, to query a VFP database, and return some information in JSON format. Yes -- it was a horrible Rube Goldberg contraption that was for a short term project to accomplish a specific task -- long ago done away with. But it was real, and it worked.
Microsoft COM is a thing for Windows. It is dated. I can see why people were simultaneously amazed and horrified with it.
[1] - that was registered when OpenOffice.org was installed
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 3, Insightful) by Unixnut on Saturday January 28 2023, @12:01AM (1 child)
And this, in a nutshell, is why MS Software has been the playground of virus writers and crackers for almost two generations now :-)
(Score: 2) by DannyB on Monday January 30 2023, @07:03PM
Yep.
As I said . . .
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 4, Insightful) by turgid on Thursday January 26 2023, @09:41PM
The reason that C is used for libraries is that the C ABI, what comes out of the C compiler, is generally the native ABI of the host operating system. It's the "native language" of the system. If your compiler/interpreter can generate code that can call C functions, you're away. The problem would be if the underlying C library made any assumptions about any regions of memory outwith its own control or if the calling language/code made any assumptions about the internals of the C library. The is an interface there and it is and should be regarded as opaque for good reason.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 4, Interesting) by JoeMerchant on Thursday January 26 2023, @09:59PM (22 children)
Fun debugging task of the day:
Splash screen was (apparently) causing a crash due to a general protection fault, in approximately 30% of system starts. This is the same splash screen code that is in use in the field with thousands of systems that show the screen several times per work day - crash means that the system fails to start, in other words we would hear about it.
Looking through the code, the pixmap that I read from disk and pass to the splash screen object is local scope. Now, I assumed (not a winning strategy according to coach Buttermaker) since it was passed by reference and because: well, if you didn't make a deep copy you'd put a big fat warning in the library documentation, I Ass-U-Me-d that the pixmap was deep copied by the splash screen object and I shouldn't sweat letting my pixmap object go out of scope before the splash screen comes down.
Apparently, with the latest gcc compiler and most recent version of the library, not. Move that pixmap object into a persistent scope: no more crashes. Could be a bug in the deep-copy logic of the latest library version, could be some twerk of gcc 11, could be that the library authors quit making deep copies in this version "for efficiency" or some such reason, without mentioning it in the primary programmer facing docs. Whatever it is it hasn't occurred in the last 20 splash-up events, so I guess I've found the fix.
20 years from now, when a decent RUST library can do what my C++ library is doing, we can all just suffer the quirks and sluggishness of the garbage collector - unless ChatGPT is doing that for us.
🌻🌻 [google.com]
(Score: 5, Informative) by Beryllium Sphere (r) on Thursday January 26 2023, @11:02PM (9 children)
What do you mean? Rust isn't garbage collected.
The bug you had sounds like the kind of thing Rust is made for. I would have expected a compile-time error from Rust code meant to implement that bug.
(Score: 4, Insightful) by JoeMerchant on Thursday January 26 2023, @11:50PM (7 children)
Give it time, Rust++ in 2030 will have garbage collection and every other water-wing accessory imaginable.
I would like to see the compiler that can unravel the mysteries of instance counting and lazy deep copy as implemented in QString, QPixmap et al.
🌻🌻 [google.com]
(Score: 3, Insightful) by Beryllium Sphere (r) on Friday January 27 2023, @01:11AM (6 children)
I've only started looking at Rust but at a guess it would not compile mysteries. Some of the examples of compile-time errors are code that's not necessarily buggy but in which the compiler can't reach a compile-time conclusion about run-time object lifetimes.
(Score: 3, Insightful) by JoeMerchant on Friday January 27 2023, @02:03AM (4 children)
That can be a good thing, or it can be unnecessarily limiting. In resource unlimited environments it's not such a big deal to restrict things that the compiler can't understand, but if you want something that works in a solar powered wireless device you probably still want that ability to be clever to conserve resources.
🌻🌻 [google.com]
(Score: 3, Informative) by RamiK on Friday January 27 2023, @03:29PM (3 children)
Nope: https://www.mdpi.com/2079-9292/12/1/143 [mdpi.com]
Incidentally, Espressif moved to RISC-V about a year ago with their ESP32-C3 core and one of their ~$20 development boards specifically targets Rust so you're getting a complete, training wheels (ide, jtag...) included, platform on it: https://github.com/esp-rs/esp-rust-board [github.com] https://www.aliexpress.com/item/1005004418342288.html [aliexpress.com] https://www.mouser.com/ProductDetail/Espressif-Systems/ESP32-C3-DevKit-RUST-1 [mouser.com]
compiling...
(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]
(Score: 3, Insightful) by bobthecimmerian on Saturday January 28 2023, @05:10PM
I'm fine with Rust, but to be clear it can do dangerous stuff in marked unsafe code blocks. So unless the whole thing is rewritten in safe Rust top to bottom, changes to the C code underneath your calls screws you just as much. (Granted, maybe your comment assumes a full rewrite.)
(Score: 3, Informative) by stormreaver on Friday January 27 2023, @02:32AM
Correct me if I'm wrong (I have only written Hello World in Rust, once, several years ago), but my understanding is that a programmer can tell Rust to ignore its memory safety rules. While the default may be memory safety, I strongly suspect that Rust programmers will frequently resort to memory-unsafety as the only way to accomplish some things.
(Score: 3, Interesting) by bzipitidoo on Friday January 27 2023, @07:57AM (4 children)
I've had programs fail to compile in newer versions of gcc because the compiler writers tightened up and quit allowing some invalid usages. For example, way back around the days of gcc 2, this incorrect code "for (int i; i99;i++) { do_things_with(i); } do_more_things_with(i);" used to work because older gcc's scoping model was too simple, and got this case wrong. The older way was simply to check that all usages of i were within the same curly braces as the declaration of i.
Sound like you've already solved it. Did you try the compiler flag -Wall? Might tell you something useful. Valgrind is a great tool for checking for memory problems.
(Score: 0) by Anonymous Coward on Friday January 27 2023, @10:20AM
I vaguely remember early versions of Visual C++ doing the same thing with for loop variable scope.
(Score: 2) by JoeMerchant on Friday January 27 2023, @10:58AM
The timing sequence is:
In the past -Wall produced almost entirely false positive concerns, so I have stuck with the default warning levels. It this point the project is a 15 minute compile time on an i7 quad-core... I am afraid of the towering wall of warnings -Wall would likely produce...
🌻🌻 [google.com]
(Score: 2) by PiMuNu on Friday January 27 2023, @11:05AM (1 child)
gcc is a pain for this. Things become warnings and valid code that used to compile and execute fine starts failing to build, because gcc authors decided it was bad style. So if *new dev* comes in with a new compiler (we have multiple partners on our code base) they hit "doesnt build for me" issues.
(Score: 2) by turgid on Friday January 27 2023, @05:39PM
In my experience, that's because it's finding bugs in the code that need to be fixed.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Insightful) by PiMuNu on Friday January 27 2023, @11:02AM (6 children)
I recommend you run valgrind before pushing the code...
(Score: 2) by JoeMerchant on Friday January 27 2023, @02:38PM (5 children)
How much has valgrind improved since 2010?
That was the last time I used it. An experienced valgrind user and I spent 2 days to get it working on our system, then it produced a huge report of memory "leaks" that weren't leaks and other things that didn't matter, and it did miss a real problem.
But, yes, valgrind should catch this kind of issue, if it doesn't somehow alter the execution flow and only see deep copy paths executed... Which is what I think happened in 2010 for the problem it missed.
🌻🌻 [google.com]
(Score: 2) by turgid on Friday January 27 2023, @04:13PM (4 children)
I used Valgrind for a couple of years from about 2015 and it seemed to be quite good. It caught some very bad bugs in a very ugly C/C++ code base of quite some size. Now don't get me started on the cause of those bugs...
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by JoeMerchant on Friday January 27 2023, @07:45PM (3 children)
It is integrated in Qt Creator, having this experience I'm going to give it a chance to catch my bug and see what happens.
The tough thing about this particular bug is that it only manifested when the app would put up the splash screen, which it only does when installed in the final product and run as delivered to customers. 99% of the time we start this program we start it without the splash screen, so it never crashes then... Also, it wasn't entirely clear that it was the splash screen causing the issue, and in the system in the field it almost never happens anyway...
🌻🌻 [google.com]
(Score: 3, Insightful) by PiMuNu on Saturday January 28 2023, @11:49AM (2 children)
This is good thing for valgrind to catch - when i've hit heisenbugs, it's been uninitialised memory where the compiler normally allocates the memory to an area that is null/false anyway; except on the odd occasion and of course, it is the user that finds it. Valgrind is useful for catching that sort of thing, where conventional testing is unreliable.
Of course, folks who never make a bug (e.g. the pope) will never end up in that situation, but I and my colleagues are fallible.
I guess that's a situation where we need memory safe language.
(Score: 2) by JoeMerchant on Saturday January 28 2023, @01:43PM (1 child)
If the Pope uses external libraries, he is still vulnerable.
I just ran CopCheck on our codebase, 90% of the findings (that matter) were in consult supplied code (which is maybe 5% of our codebase.)
🌻🌻 [google.com]
(Score: 3, Funny) by PiMuNu on Saturday January 28 2023, @03:38PM
> If the Pope uses external libraries, he is still vulnerable.
Damn those protestants.
(Score: 3, Interesting) by DannyB on Thursday January 26 2023, @10:18PM
See Java and C#. Both of these have a common underlying runtime system below the programming language. I will use Java as an example, but the same applies to C# and .NET.
You can write source code in Java or other languages that compile to JVM bytecode. All of the bytecode runs on the JVM (Java Virtual Machine). (In .NET this would be the CLR, or common language runtime)
Memory management and GC happens in the JVM, not the Java language. All pointers, objects, arrays, primitive scalar types, etc are compatible across languages. You CAN pass objects from one library into another library. Everything obeys the same memory management discipline, specifically the JVM's GC.
What makes all languages on this platform fully interoperable is that they "compile" down to a common runtime system with shared basic types and memory management. So Clojure code can interoperate with Java code and structures and vice versa. Kotlin can interoperate with Java. Scala can interoperate with Java.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 2) by bart9h on Thursday January 26 2023, @11:04PM (2 children)
But there's no garbage collection in Rust. The memory safety comes from elsewhere: the language has strict rules about data (memory) ownership, and the compiler do a hard working enforcing them. Which also makes it painfully slow.
(Score: 2) by Beryllium Sphere (r) on Friday January 27 2023, @01:13AM (1 child)
You mean painfully slow to get a program to build? It's designed to run comparably fast to C++. Or do you mean it slows down the compiler? I've never seen benchmarks of the compilers.
(Score: 3, Interesting) by bart9h on Friday January 27 2023, @02:43AM
Sure you mean "comparably slow to C++"?
C++ compiler is already slow as hell, and eats lots of RAM too, specially when you use lots of templates.
Try compiling some large D code to see what a fast compiler feels like.
(Score: 2) by progo on Thursday January 26 2023, @08:49PM (3 children)
I followed the link « Bjarne Stroustrup and his peers, to devise a plan for the "Safety of C++" » and it just kept infinite looping to a blog post that transcludes related text that contains this link to the same URL. What did Stroustrup actually say?
I think they're referring to this PDF published last month. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2739r0.pdf [open-std.org]
(Score: 5, Insightful) by Anonymous Coward on Thursday January 26 2023, @09:25PM (2 children)
In a nutshell, static checking of existing C and C++ code can do a lot of what Rust and friends do without forcing a wholesale re-write of billions of lines of existing code. I agree, and have wondered what kinds of types and/or qualifiers could be added to C in order to support such safety. Then it would be a matter of adding some compiler warnings and actually requiring releases to compile without triggering them. There's an awful lot of code out there that honks when compiled with -Wall for no legit reason other than people not wanting to clean up their code.
(Score: 4, Informative) by turgid on Thursday January 26 2023, @09:37PM (1 child)
Bingo!
When you go to write new code you should set, as a bare minimum, on the compiler command line -Wall -Werror -pedantic. You should also do TDD. You shouldn't write a line of code without a unit test case with at least one assert() in it.
In recent years, gcc has become very helpful at telling you when you might overflow string buffers. In years past, you used to have to pay for third party static analysis tools to do that sort of things.
Make sure you understand the difference between the BSS, heap and stack. Understand how array bounds work. Understand array dimensions and pay close attention to the types. Read the C Programming FAQ.
Understand that address 0 is special. Understand that memory comes uninitialised by default unless you declare static. Do you know what volatile is for? What's the difference between an integer and a pointer? What's special about function pointers?
What are the catches with string literals vs arrays of char?
Which C library functions are unsafe, and were therefore bad designs? Which C library functions are better?
When is using malloc() and free() a bad idea? What are the alternatives?
What should happen when the machine runs out of virtual memory?
How are mutexes implemented at the hardware level? Cache coherency? Bus snooping?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2, Funny) by shrewdsheep on Friday January 27 2023, @09:52AM
You should order some new.
(Score: 2, Interesting) by zzarko on Thursday January 26 2023, @09:28PM
... [to make a strategic shift away from C++0] in favor C#, Java, Ruby, Rust, and Swift.
EXACTLY the languages I'm not using. Well, maybe Rust one day, the rest not so...
C64 BASIC: 1 a=rnd(-52028):fori=1to8:a=rnd(1):next:fori=1to5:?chr$(rnd(1)*26+65);:next
(Score: 3, Interesting) by turgid on Thursday January 26 2023, @09:49PM (1 child)
....I WILL get around to trying out D [dlang.org].
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Funny) by DannyB on Thursday January 26 2023, @10:35PM
There were quite a few years where I kept saying that to myself.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 2) by Mojibake Tengu on Friday January 27 2023, @04:22AM (4 children)
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2739r0.pdf [open-std.org]
So Bjarne Stroustrup thinks otherwise.
But let's keep spinning memory safety, it's funny thing. A nutritious food for socnet activism, if well served.
Respect Authorities. Know your social status. Woke responsibly.
(Score: 2) by Mojibake Tengu on Friday January 27 2023, @04:34AM (3 children)
Let me state it more brutally: memory safe language equals prosthesis for stupidity. It can help you hobble, but does not enable you to sprint.
Disclaimer: I write assembly. For me, all the memory around the address space is safe enough.
Respect Authorities. Know your social status. Woke responsibly.
(Score: 2) by PiMuNu on Friday January 27 2023, @11:14AM (1 child)
There isn't much overhead in e.g. c++ memory library.
(Score: 2) by Mojibake Tengu on Saturday January 28 2023, @02:51AM
I hold no prejudice against C++ and its facilities. I consider it safe enough too.
If I had to use it for big stuff, I'd probably write explicit accessors to my classes for additional safety with stray pointers. Just like what I do in assembler. A masked-checked accessor operator which guarantees 'no unsafe overrun' only is one instruction overhead.
Respect Authorities. Know your social status. Woke responsibly.
(Score: 3, Insightful) by bobthecimmerian on Saturday January 28 2023, @09:33PM
For the overwhelming majority of software - admittedly not all - developer productivity is more important than efficiency. It's horrifically wasteful, but that's the world we occupy. I can write safe C++. What I can't do is write safe C++ as quickly as I write Java/JS/Perl/Ruby, and all of my employers care more about speed than efficiency.
As long as modern capitalism continues, that won't change. So most of our industry has a reason to choose memory safe languages.
(Score: 3, Insightful) by VLM on Friday January 27 2023, @02:40PM (1 child)
Everyone carefully notice that ancient quarter century old Java didn't do the trick, clearly we need a trendy new language, that'll do it this time, surely we won't be having marketing in the year 2050 explaining how some new miracle language will soon be the final solution to the non-memory safe C++ question.
(Score: 3, Interesting) by bobthecimmerian on Saturday January 28 2023, @09:25PM
Or LISP before it - and I love Lisp. Or Smalltalk.