Now that doesn't mean Linux stable kernel maintainer Greg Kroah-Hartman thinks Rust is magic:
At the Rust Week conference, the world's biggest Rust language conference, in Utrecht, Netherlands, Linux stable kernel maintainer Greg Kroah-Hartman opened by saying: "I'm here to talk about untrusted data and Linux, and how Rust is going to save us." After "a long month or two on the kernel security list," he pushed that point even further: "I'm going to make even a bolder statement and say, 'You are going to save Linux.' Sorry, it's all on you."
What he was talking about was the sudden flood of serious Linux security holes being discovered, such as Dirty Frag, Copy Fail, and Fragnesia, that have come to light thanks to the latest AI bug-detection programs.
As a result, Kroah-Hartman, who has "seen every single kernel security bug ever" since 2005, said the kernel team is now issuing "13 CVEs [Common Vulnerabilities and Exposures] a day, or something, something crazy." He thinks Rust is one of the few realistic ways to slash the class of bugs that come from C's traditional error-handling and resource-management pitfalls.
Kroah-Hartman illustrated those pitfalls with real C bugs in the kernel, including a 15-year-old Bluetooth bug that dereferenced a pointer without checking it and a Xen bug where "we forgot to unlock" in an error path. "The majority of the bugs in the kernel are this tiny, minor stuff," he explained. "Error conditions aren't checked, locks aren't forgotten, unreleased memories leak, and vulnerabilities add up over time. They crash the kernel. This is what we live with in C. This is why we don't like it."
Kroah-Hartman argued that the "best beauty of Rust" is catching those mistakes at build time rather than in review. For example, when it comes to locking, he highlighted Rust's locking abstractions in the kernel: "The only way you can get access to inner pointers of structures is by grabbing that lock, and releasing the lock automatically. The compiler does it, it's guarded, the lock happens, everything's happy. You just can't write code to access these values...without grabbing the lock. The compiler will not let you."
Those properties, he argued, directly remove a huge fraction of the bugs he sees: "This is going to save us those two things. First, 60% of the bugs in the kernel right there, they're gone. Thank you." The payoff is earlier, more automated enforcement: "If this happens at build time, not review time, don't make me a maintainer who has to read your code [and] say, 'Oh, then you properly check that error value. Oh, did you properly grab the locks in the right spot?' Rust gives us that for free. This is the best thing ever."
Even if Rust vanished tomorrow, Kroah-Hartman argued, it has already forced the kernel to clean up C code and interfaces. He credited Rust's influence outright: "We stole this from Rust. Thank you. It's a good idea, so if Rust disappeared tomorrow, we have cleaned up the C code in the kernel so much and taken in the ideas. We thank you, you've made Linux better with it just by existing."
[...] Now, that doesn't mean he thinks Rust is magic. It's not. He cited one of the first Rust components merged into the kernel: QR code display logic used when the kernel crashes. "That logic was written in Rust. Famously, it had a memory bug. It was given a buffer and its size, and the rest of the st code never checked the buffer size... Could scribble all over memory, because Rust can crash just as bad as C." So, Rust "is not a silver bullet."
He's also not encouraging anyone to rewrite the Linux kernel in Rust. One attendee asked, "Do you actually encourage rewriting stuff that's already there in the kernel with [Rust]?" Greg replied: "No, we don't want rewrites, so unless you're the maintainer and owner of that file, just do it for new stuff. Leave existing C code alone, and let's evolve forward after that." He gave Binder, Android's core interprocess communication (IPC), as an example where both C and Rust implementations coexist temporarily to reach parity, after which "they're going to delete the C code, because I trust them, and they are the owners and maintainers of both those."
[...] What ultimately sold a number of core maintainers, including him, on Rust was how it "makes reviewing code easier." With CI [Continuous Integration] bots enforcing builds and Rust's type system enforcing key invariants, maintainers can "focus on the logic" rather than resource bookkeeping: "I can care about that one function. I don't have to worry about the rest of this stuff, because I assume that it works properly, because it was built properly."
Internally, he said, the top maintainers have already made their call on Rust's status: "The Linux kernel maintainers, we get together every year and talk about what the processes are doing. Last year, we said the Rust experiment is over. It's not an experiment. This is for real." The rationale: "The people behind it are real. We trust them. We know what they're doing. They've shown and put in the work to make Rust a viable language in the kernel, and we're going to make this stick. Let's go full speed ahead. And, as always," he said wryly, "world domination proceeds."
(Score: 5, Interesting) by JoeMerchant on Tuesday June 02, @06:11PM (9 children)
While it's nice to be perfect,
And, in those 15 years, how many real problems came from that dereference without check? Maybe the programmer just got lucky, maybe they knew it didn't need checking due to previous steps which ensure it is valid/good. Is it bad practice in code which others can pick up and get cut on the razor blades you leave sticking out between the pages? Sure. But, is it really a bug?
Effectively, what we have now are LLM based code reviewers that can get as anal-retentive as you like about best practices in C, find and insist on "fixing" these old maybe bugs with proper pointer checking before EVERY dereference that could POSSIBLY need it. The LLM tools are the source of all the transparency into "what's lurking in the code base" - but Rust isn't really any better answer than just following best practices for C - including reviews that catch these "issues."
🌻🌻🌻🌻 [google.com]
(Score: 5, Funny) by shrewdsheep on Tuesday June 02, @07:04PM (1 child)
I believe formal verification helps. In C memory management in the heap is manual malloc/free. In C++ this is formalized for objects living on the stack. Then C++ has smart pointers that help with tracking of other resources but is based on convention, not being formalized. Rust formalizes all/most resource management. Languages will come after Rust that formalize even more like automatic proofs of pre/post-conditions.
(Score: 3, Informative) by JoeMerchant on Tuesday June 02, @07:12PM
Qt started pushing javascript (Quick) 15ish years ago, I never succumbed.
🌻🌻🌻🌻 [google.com]
(Score: 5, Insightful) by bzipitidoo on Tuesday June 02, @10:28PM (5 children)
But that's one of the big tradeoffs purposely made in C: Trust the programmer. For the sake of speed, C does little to no checking, relying on programmers to explicitly code such checks, or not. There can be good reasons to not check every little thing. However, as we've seen in the rush to get things done, checking for every little thing is often given short shrift. Often, programmers aren't making an informed choice to not check things, they're skipping the checks to save themselves time and effort and meet deadlines. Even when deliberate, it has often proved a mistake to skip sanity checks. One example is, suppose you have a small array of 256 elements, and you use an unsigned char to index into the array. That can't ever go out of bounds, so there's no need to check for out of bounds, right? Well, no. Unsigned char is not guaranteed to be exactly 8 bits, it is only guaranteed to be at least 8 bits. Some system that uses 16 bits (or whatever amount greater than 8) for unsigned character could go out of bounds. Oops. This could be avoided by doing a bitwise AND of the index value with 255, just one extra instruction, but that is a performance hit even if only a tiny one.
The Spectre vulnerability in so many CPUs is similar in that the CPU delays some memory access checks too long, in the interest of performance. That class of vulnerability affects CPUs in Intel's case all the way back to the Pentium Pro, over 20 years before its discovery and publication. 20 years! And how did CPU manufacturers respond? They equivocated. They did not want to really fix the vulnerability, not when it cost performance. They tried to mitigate it in ways that would not decrease performance.
I expect that LLMs will not continue to find security vulnerabilities at their current pace. Once they've uncovered all of the glut they're so suited to find, the bug finding will slow back down.
I have a fondness for the idea of starting over from scratch. As in, build an entire new computing architecture and OS based on all the things we've learned over the decades but which we've not been able to fully implement because of existing limitations and requirements. While at it, also redesign networking and web page architecture. Just finally dumping IPv4 for IPv6 would be good. Really, HTML is bloated, but that has become somewhat irrelevant in the face of web design deliberately adding bloat that isn't necessary and which would not be addressed by streamlining HTML (or HTTP beyond what such projects as Google's SPDY achieved), not to mention that HTML traffic is now a minuscule part of all network traffic, the vast majority of which is now video. Still, seems a worthy project. I don't know about going as far as, say, dumping UTF-8 for something "better", but could consider such notions. Such a big reboot would allow the jettisoning of all sorts of cruft, such as decimal arithmetic in the CPU. Maybe that's a bad idea, and continuing the approach of refining the existing code and systems is best. For instance, turns out that RISC-V, which seems a really great way to at last sunset crufty x86, is also vulnerable to Spectre. Well, cross compiling and architectures have advanced to the point that the underlying target architectures are pretty interchangeable, thus allowing the separation of an architecture reboot from a big reboot of everything. Have to go clear back to the 80386 to find an x86 architecture lacking in important capabilities. An example of such a reboot on a much smaller scale was the move from Gnome 2 to Gnome 3. Narrowing it down even further, I learned that Eye Of Gnome (Gnome's image viewer utility) is being entirely replaced by Loupe. I took Loupe for a spin, and quickly discovered that Loupe is still inferior in its handling of corrupted and incomplete images, refusing to show the user anything at all, whereas EOG shows all of the image that is available.
(Score: 5, Interesting) by istartedi on Tuesday June 02, @11:28PM (1 child)
This could be avoided by doing a bitwise AND of the index value with 255, just one extra instruction
Yes, but a better way is to index the array with uint8_t which is what you really meant in the first place. In the ASCII era it was always the same as unsigned char, and that's often still the case. The explicit type cast to uint8_t will only have a cost if you actually rebuild on a system where it needs to happen. Now, about the rollover. We're assuming the rollover is OK but is it? That's a big "it depends". Hilarity might ensue from rolling over in to the low ASCII range where control codes live. Like, BEL and form-feed anybody? This is what I love and hate about programming at the same time--simple things that are really not simple.
Appended to the end of comments you post. Max: 120 chars.
(Score: 4, Interesting) by JoeMerchant on Wednesday June 03, @12:08AM
Back in the day, I ported a DOS GUI library (Menuet) from 16 bit to a 32 bit architecture, there were about 2 clever tweaks I had to make in the whole code base, the rest of the port work was find and replace int with int16_t.
🌻🌻🌻🌻 [google.com]
(Score: 2) by JoeMerchant on Wednesday June 03, @12:06AM
>I expect that LLMs will not continue to find security vulnerabilities at their current pace. Once they've uncovered all of the glut they're so suited to find, the bug finding will slow back down.
I expect so, too... except in those situations where people are stubbornly refusing to use LLMs even to review code, and I have seen more than one of those. Thing is: if you don't use LLMs to review your own code, sooner or later somebody else will...
> dumping UTF-8 for something "better"
Now I'm having visions of the NeXT box, remember that one? Doing something better isn't a ticket to success when the world continues to do it the old way.
I actually like UTF-8 and similar schemes - I'd like to develop a system of infinite precision arithmetic based on a similar number encoding: 1 byte for up to 2^7, 2 bytes for up to 2^14, 3 bytes for up to 2^21... if you're throwing out the byte as a unit you might be able to optimize that differently, but the core thought remains: for that vast majority of cases where you're throwing around small numbers, keep them stored and processed in small amounts of memory...
> cruft, such as decimal arithmetic in the CPU
I also liked my Atari BASIC which did BCD integer math - well worth the efficiency loss these days, IMO. Humans operate in base 10, why are we translating our numbers out of base 10 and back to it with a lossy scheme?
> I took Loupe for a spin, and quickly discovered that Loupe is still inferior in its handling of corrupted and incomplete images, refusing to show the user anything at all, whereas EOG shows all of the image that is available.
I bet 40 hours with Claude code and you could easily bring Loupe up to speed with everything you miss from EOG, I also bet it would be 10x the effort to get the Loupe team to merge your improvements, and 100x the effort to get the community to recognize your fork.
🌻🌻🌻🌻 [google.com]
(Score: 5, Informative) by lars_stefan_axelsson on Wednesday June 03, @08:28AM
That's one "problem", but I would say that a bigger problem today is that C semantics (underspecified as they are) are not what most C programmers think they are. (Many sources, but here's a lecture that gets to the heart of the matter: https://www.cl.cam.ac.uk/teaching/1415/CandC++/lecture10.pdf [cam.ac.uk]
This has led to a whole slew of "new" bugs, even in code that worked well enough before, to really show the weakness of the C approach.
Trusting the programmer is alright, just up until you pull the rug from under their feet (on purpose)...
Stefan Axelsson
(Score: 3, Interesting) by VLM on Wednesday June 03, @02:28PM
I'd agree with your post although I'd propose a bigger problem is higher level impact on C. The problem can be so much higher level.
So perhaps at a high level software architecture/process the TCP segment reorder code is separate from the ethernet driver code. Because "why not".
Well the TCP segment reorder programmer can define a buffer for each incoming ethernet packet as a C constant lets say 1600 bytes because MTU of classic ethernet is 1500-ish. The ethernet driver guy working completely independently might use a slightly different number, but as long as BOTH are more than the max data that can come from standard ethernet, its all good, right?
What if "they" in higher management levels decide to support jumbo 9000 byte ethernet frames. Well obviously we patch the ethernet driver to allow large frames and increase the driver buffer to 9500 bytes or so, build, test, it works with 9000 byte ICMP pings, works with all UDP traffic, whatever your using for TCP testing maybe doesn't even support jumbo frames or you never think to test or you test by running telnet which will never generate packets larger than a couple hundred bytes in normal CLI use ... it seems to work ... So ship it.
Then anyone can smash the stack and exploit by sending jumbo TCP frames. Whoops.
Whats the failure mode and how to fix it? Well I donno. A better architecture would be setting buffer sizes only via global constants or math performed on global constants. Or smarter managers might realize the driver and protocol networking code is more closely linked than they expected and should have been done by the same dude. Or "we should make it illegal to use strcpy only strncpy is allowed" which costs performance. Could rewrite it in golang which would work or write it in Rust which will be slower and harder to use, but Rust is yet another humiliation ritual so the usual people really like Rust for that non technical reason. Or implement a more advanced unit test suite. Or hire cybersecuritytheater guys to work on often exploited code (which I guess is all of it, now a days)
I think I ran into the above story about jumbo frames like a quarter century ago, although I don't think it was linux. The overall story was correct it was something like some dude made 1600 byte buffers because ethernet frames longer than 15?? are illegal and will be filtered by the driver and 1600>15?? so 1600 is large enough. LOL not so.
(Score: 2) by bart9h on Wednesday June 03, @08:06PM
Maybe not for the author of the code, but certainly yes for the reviewer.
(Score: 5, Insightful) by VLM on Tuesday June 02, @06:34PM (5 children)
Rust is the new embrace extend extinguish "EEE"
(Score: 3, Touché) by Unixnut on Tuesday June 02, @09:15PM (4 children)
I was just thinking in response to the headline: "and what will save Linux from Rust?" XD
(Score: 4, Funny) by bzipitidoo on Tuesday June 02, @11:17PM (2 children)
I propose a new language, based on ALGOL: ALGOrithmic Higher Order Language, or ALGOHOL! ALGOHOL code will be so clean it will make Rust look old, corroded, and nasty!
Who comes up with such terrible names as "Rust" anyway? Stupid joke name for a programming language that's supposed to enforce cleaner coding, naming it after the results of treating iron in a very dirty and corrosive way! So Rust is actually named after a much hated fungus that damages crops. Might be even worse than being named after a form of metallic corrosion! That's a name for a virus (computer or biological), not a programming language. Ranks up there (or down there) with such names as The GIMP and Plan 9 OS, WinCE, and mascots such as Beastie, the FreeBSD mascot. And Yahoo. Great nerd cred, perhaps, sticking it to the normies and marketing freaks by embracing such names, but come on.
(Score: 2, Touché) by Anonymous Coward on Wednesday June 03, @01:19AM
> ALGOHOL code will be so clean it will make Rust look old, corroded, and nasty!
Ada anyone?
(Score: 2) by VLM on Wednesday June 03, @02:33PM
Reminds me of ethanolfueled I wonder whatever happened to that guy.
(Score: 0) by Anonymous Coward on Wednesday June 03, @03:33PM
Add rust to the pile along with wayland. Let's break linux at a critical time when it's most needed. I long for the days of fragmentation, don't you?
The servers that commercial entities use won't be as affected. They really hate the desktop.
(Score: 3, Interesting) by turgid on Tuesday June 02, @07:46PM (6 children)
Kroah-Hartman argued that the "best beauty of Rust" is catching those mistakes at build time rather than in review. For example, when it comes to locking, he highlighted Rust's locking abstractions in the kernel: "The only way you can get access to inner pointers of structures is by grabbing that lock, and releasing the lock automatically. The compiler does it, it's guarded, the lock happens, everything's happy. You just can't write code to access these values...without grabbing the lock. The compiler will not let you."
How long has it taken the human race to get to this point? This has been obvious to me for well over 30 years. I never had the skill to write a compiler, but surely someone with more brains that I had already done it? Oh, the language didn't have curly brackets? So it didn't catch on?
I was hoping I might live long enough to see a human Mars base. Given that I was born well after the Moon landings were ancient history, I thought that was quite a reasonable thing to hope.
With each new day and with each new revelation, by despair deepens.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by JoeMerchant on Tuesday June 02, @07:51PM
I feel like I was getting this from (multiple) C++ API libraries 20 years ago. Just use the API like you're supposed to, all sorts of things happen automagically.
🌻🌻🌻🌻 [google.com]
(Score: 2) by JoeMerchant on Tuesday June 02, @07:56PM (4 children)
>I was hoping I might live long enough to see a human Mars base. Given that I was born well after the Moon landings were ancient history, I thought that was quite a reasonable thing to hope.
Colombus sailed the ocean blue in good 'ole 1492.
St. Augustine - first permanent European settlement in the Continental US - didn't happen until 1565, 73 years later... 1969+73 = 2042. We might have a start of a planned moon base by then... To be fair, Florida is a little easier to inhabit than places without air.
🌻🌻🌻🌻 [google.com]
(Score: 3, Funny) by Anonymous Coward on Tuesday June 02, @08:05PM (2 children)
Source? Cite? :)
(Score: 3, Touché) by JoeMerchant on Wednesday June 03, @12:12AM (1 child)
Sea of Tranquility, visited in 1969, must have gotten a bad review, nobody has been back since.
🌻🌻🌻🌻 [google.com]
(Score: 2) by turgid on Wednesday June 03, @07:19AM
Plus no gators. How are you meant to make s new pair of boots?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by DannyB on Wednesday June 03, @06:59PM
Colombus sailed the deep blue sea in good 'ole 1493.
Stupid people exist because nothing in the food chain eats them anymore.
(Score: 4, Interesting) by Rich on Tuesday June 02, @08:23PM (5 children)
In the 80s, I was under the impression that C was being forced onto the computing world by higher powers. Pascal was a perfectly fine systems programming language, as shown by the UCSD System, the Lisa, and the Mac. C was vastly inferior with regard to stability as it arrived, and it has hardly gotten better. The Pascal evoluton was unrivaled by anything C, through Turbo Pascal, Apple's Object Pascal, and finally Delphi. So the broad acceptance of C may well have been orchestrated, much as the Rust push is now. Nice conspiracy theories, anyway. :)
But aside from that, the C world has had a quarter of a century to get their stuff in order, and they didn't, so the C/C++ demise is self inflicted for the largest part. It would have not been hard to create a slightly modified language that's free from most of the breakage, as demonstrated by the Oberon experiment. Proper separation of call-by-reference and arrays, with range checks for the latter would have gone a long way. RTTI, ref-counting, and overflow checks would have sorted the rest. For convenience, they could have massaged the preprocessor to properly allow textual generics, and added shared code generics to the type system. Add a module system for compile speed, and you're done. (C# might have made it if they had proper GUI libs for all platforms and RC rather than GC (so realtime was covered). I once wrote a bit of stuff in the very similar Vala, and it was a pleasure.)
Instead we get C++ "concepts" to somehow, but only optionally, force the weird ways of the C++ committee on developers. While the developers just could use FreePascal/Lazarus, but instead (including me) follow (or have to follow) the herd. (Actually, even FreePascal developers follow the herd with their angled-bracket syntax for generics, rather than staying in the tradition of creating a Language.
(Score: 3, Interesting) by PhilSalkie on Tuesday June 02, @09:10PM (2 children)
Or we could put some time into making the C internal operations safer - have a look at Fil-C (based on clang) https://fil-c.org/ [fil-c.org]
From their website:
Fil-C is a fanatically compatible memory-safe implementation of C and C++. Lots of software compiles and runs with Fil-C with zero or minimal changes. All memory safety errors are caught as Fil-C panics. Fil-C achieves this using a combination of concurrent garbage collection and invisible capabilities (InvisiCaps). Every possibly-unsafe C and C++ operation is checked. Fil-C has no unsafe statement and only limited FFI to unsafe code.
(Score: 4, Interesting) by turgid on Tuesday June 02, @09:31PM
See those "advanced runtime checks?" 30-40 years ago they were possible too (and other languages did them) but C did not. The reason was to get every last ounce of performance out of the system. Computers are now millions of times faster and that overhead is not a problem (mostly). I suppose it's about time someone put those features into C and C++ compilers. Before you know it, they'll be on a par with Turbo Pascal with array bounds checking turned on.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by Rich on Wednesday June 03, @12:24AM
I did look at Fil-C before, and it's quite amazing. It does a good part of what Valgrind does, bot with a 2x instead of 100x speed penalty. The guy has built a super complicated runtime system to keep 100% syntax compatibility. It's fast enough that you could it for making some, but not all, existing codebases safe. Fine for server class applications. But in cases where you really want to know what's going on with every bit down to the instruction level (embedded), it's not the right choice. In the C world. this could really only be made safe (read UB free) with changes to the language itself.
(Score: 3, Interesting) by turgid on Tuesday June 02, @09:28PM (1 child)
I remember when C was the cool new language on PCs in the 80s. There was a good reason for that. Computers at the time were very small and slow and the extra efficiencies of C were very important. It really was a thin layer above writing in assembly language. Also, it was the first high-level language in which a portable operating system (Unix) had been written. Pascal was a very nice language indeed, but it was in something of a sandbox. If you needed the extra power and control, C gave you that for free.
Modula-2 came out at a similar time and it was a great successor to Pascal. However, C++ came along and it was ostensibly a better C so it caught on.
C++ became a baroque monstrosity and something of a cult. The world is still suffering. Then someone came up with Rust, which is re-inventing Ada with curly brackets, slowly. They'll catch up eventually.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Interesting) by Rich on Wednesday June 03, @01:04AM
I remember that I didn't see the point of C. You could do everything on an 8-bit Z80 in Turbo Pascal, or on the Mac in Lightspeed Pascal, and that even had a full object system. The code wasn't noticeably slower for any application I came across. And this was for CPUs with their roots in the 70s. If you really, seriously, needed the last cycle, you'd write the inner loops in assembly, which in turn was faster than C. C's pointer math features, even back then, were overestimated in their gains, and beyond that, C had nothing to offer over Pascal. But once C moved in, with it came the memory errors. It might have disturbed people that Pascal systems spat out complete applications in seconds, where the C ecosystens had all the hassle with preprocessor, compiler, archiver, and linker stages, which made them appear more "serious"..
Modula-2 was nice, but even more than an object system, and like Oberon that followed it, it lacked the ability to write native applications for most mainstream platforms. I think the Amiga had a Modula-2 with reasonable bindings, but to my knowledge, nothing for the Mac (and later the PC) existed. Around 1999, I worked for a Delphi shop, and even with my dislike for PCs, that was another dimension compared to the (early) C++ environment I had to deal with before. Now said C++ environment has caught up with me a few years later, and I've been maintaining it ever since. But I have the comparison to know how much better things could be. Rust has other downsides btw, it's the annoying ways the language dictates what is possible, and real-world developers then have to find their ways around these restrictions.
(Score: 4, Insightful) by Anonymous Coward on Tuesday June 02, @08:28PM (1 child)
And all it costs is *ALL* of the current kernel maintainers! How inexpensive!
Don't worry, I'm sure Microsoft will be forthwith presenting its credentials for stewardship. And then forking, and oh! Look! It's recently started its own release. See! They come with experience!
(Score: 0) by Anonymous Coward on Wednesday June 03, @03:35PM
Experience on turning it into windows part 2. Rent seeking boogaloo.
(Score: 3, Insightful) by Bentonite on Thursday June 04, @04:13AM
That memory errors are fraction of security vulnerabilities and that most vulnerabilities are logic errors.
How rust needs 12-160x the lines to implement the same thing as GNU C, means that rust rewrites that implement the same functionality, will therefore contain 12-160x the amount of bugs.
Memory errors are easy to find with static analysis tools and even LLMs it seems, but the insidious logic error is much harder to find.
You can either make something so simple that there are obviously no deficiencies, or make something so complicated there are no obvious deficiencies and rust does the latter.
(Score: 3, Interesting) by Techwolf on Friday June 05, @11:23PM
C++ with std:: solved this years ago. Rust is the buzzword for marketing like AI is the new buzzword for LLMs.