do memory safe languages matter less now? [LWN.net]

do memory safe languages matter less now?

Posted Apr 22, 2026 15:26 UTC (Wed) by bertschingert (subscriber, #160729)
Parent article: Firefox: The zero-days are numbered

I wonder if this weakens the argument for using languages like Rust over C. If AI can reliably find nearly all security bugs in a C codebase, how much of an advantage do the static checks of Rust provide?

Of course, all the other reasons to use Rust still apply. But a year ago a common attitude was "it's irresponsible to write new software in memory unsafe languages", and I wonder if now it will become "it's irresponsible not to subject your software to AI security review, but writing it in C is fine."

to post comments

do memory safe languages matter less now?

Posted Apr 22, 2026 15:52 UTC (Wed) by josh (subscriber, #17465) [Link] (5 responses)

On the contrary, I think it *strengthens* the argument for memory-safe languages, and other mechanisms that fix whole categories of security issues.

These models, once more widely available, will massively shorten the time from "shipped vulnerable code" to "discovered and exploited vulnerable code". It's going to be important to eliminate entire classes of vulnerabilities, so that we can do ongoing development with more confidence.

do memory safe languages matter less now?

Posted Apr 22, 2026 18:46 UTC (Wed) by wtarreau (subscriber, #51152) [Link] (3 responses)

> On the contrary, I think it *strengthens* the argument for memory-safe languages, and other mechanisms that fix whole categories of security issues.

From the few bug reports I had the opportunity to see, the tool is powerful enough to find complex logic bugs. That places all languages on the same ground. And I would even suggest that some simple usual traditional operations that force you to more complex approaches in memory safe languages to satisfy the compiler's imposed constraints might even be more likely to trigger logic bugs than in traditional languages precisely because of the difficult constraints. So... we'll see.

I think that for now these tools are mostly trained on existing code base and that C, PHP, JS and Python are so much common that they might be more efficient there than on newer and less represented languages like Rust or Zig for example. Thus even the initial statistics do not mean much for the long term. This is an area that progresses in big steps.

do memory safe languages matter less now?

Posted Apr 22, 2026 21:44 UTC (Wed) by josh (subscriber, #17465) [Link] (2 responses)

All languages aren't on the same ground for logic bugs, either. For instance, I think ADTs that support matching, with errors for non-exhaustive matching, help eliminate many logic bugs.

I do think these tools will find bugs in code in every language. The question is where it finds *more*, and which ones are exploitable.

do memory safe languages matter less now?

Posted Apr 23, 2026 8:11 UTC (Thu) by NAR (subscriber, #1313) [Link]

Those stack overflows and stuff can enable the attacker to completely take over the program. Logic errors can be also serious (e.g. transfer money from other people's account), but rarely give complete access to the attacker.

do memory safe languages matter less now?

Posted Apr 24, 2026 9:22 UTC (Fri) by taladar (subscriber, #68407) [Link]

Iterators and functional handling of containers with map/filter/fold/... style higher order functions also eliminate a whole lot of bugs in traditional C loops and in fact contrain what can happen there significantly (e.g. map can never change the number of elements, filter can never increase it,...)

do memory safe languages matter less now?

Posted Apr 23, 2026 15:29 UTC (Thu) by jorgegv (subscriber, #60484) [Link]

Point is, these AI scanners are currently very cost-effective: for a few bucks/mo you can run it over all your code base... which makes it easier to just plug the security review _before_ you "ship vulnerable code".

The AI tools are there for the baddies, but also for code writers. They have just upped the baseline for everyone.

do memory safe languages matter less now?

Posted Apr 22, 2026 16:56 UTC (Wed) by farnz (subscriber, #17727) [Link] (1 responses)

It all depends crucially on costs.

We moved from assembly to higher level languages like C in large part because the cost of doing a good enough job in C was much lower than the cost of doing a good enough job in assembly; not just the financial cost, but also the time cost.

If the comparison is "Rust with AI vulnerability finder" versus "C with AI vulnerability finder", then the question becomes which is cheaper - if you spend significantly more money on the AI for C, and then significantly more time, it'll push people to Rust. If the AI costs for checking Rust are higher, and the time to a releasable product is higher, people will stick to C.

I second the cost factor

Posted Apr 23, 2026 4:13 UTC (Thu) by felixfix (subscriber, #242) [Link]

I was fascinated by both machine language and assembler, but two things make them too expensive. One is the obvious that it simply takes longer to write assembler (and machine language is orders of magnitude worse for anything more than a few lines), plus branching requires labels and those get hard to keep track of. The other is optimization. It's easy enough to memorize instruction timings for an 8008 or even Z80; it got beyond fun with the 68020; and I would say it;s impossible for modern CPUs, although I've never tried assembler for any RISC machine.

I liken it to hand tools vs power tools. A lot of assembler coding is the equivalent of hammering in nails or driving in screws. It gets boring fast, and it slows everything down for no enjoyable reason. As much as I enjoyed those old assembler days on those simple processors, they were not productive, and the satisfaction of seeing code run, first time, in an hour or two, beats days or weeks of assembler trial and error. Humans are good at thinking. Leave the repetitive boring error-prone stuff for computers.

do memory safe languages matter less now?

Posted Apr 22, 2026 17:07 UTC (Wed) by smurf (subscriber, #17840) [Link]

It's an order of magnitude less effort to write your code in a safe language with interfaces which deserve that name and include compiler-enforced guardrails, than to mostly-not-document safe usage of C interfaces – then retroactively find more-or-less-complicated patterns which enable C code to jump over them.