Rust Will Save Linux From AI, Says Greg Kroah-Hartman 168
Linux stable kernel maintainer Greg Kroah-Hartman says Rust can help Linux deal with a flood of AI-discovered security bugs (namely Dirty Frag, Copy Fail, and Fragnesia) by preventing common C mistakes around memory, locking, error handling, and untrusted data at build time rather than during human review. It's "not a silver bullet" and does not mean rewriting the whole kernel, but he said new drivers and subsystems will increasingly use Rust as Linux evolves forward. ZDNet reports: 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."
[...] 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." "If you never remember anything else in my talk, just remember these four words. It came from Microsoft Security many, many years ago," Kroah-Hartman told attendees. "They realized all input is evil. You have to validate all input."
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."
[...] 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." "If you never remember anything else in my talk, just remember these four words. It came from Microsoft Security many, many years ago," Kroah-Hartman told attendees. "They realized all input is evil. You have to validate all input."
Wait, 4 words? (Score:4, Insightful)
"If you never remember anything else in my talk, just remember these four words. It came from Microsoft Security many, many years ago," Kroah-Hartman told attendees. "They realized all input is evil. You have to validate all input."
Which four words are we supposed to remember?
Re:Wait, 4 words? (Score:5, Informative)
"All input is evil"
Re: (Score:3)
"All input is evil"
It was a slide he displayed around 27m 20s in his talk before the RustNL group
Re: Wait, 4 words? (Score:2)
Re: (Score:2)
Somebody forgot to validate the word-count
Re: (Score:2)
All Input Is Evil
Re: (Score:2)
It is that obscure Perl feature, tainted mode.
Re:Wait, 4 words? (Score:4, Informative)
That's not entirely true, all data is potentially valid Perl, depending on how you set some variables.
Re: Wait, 4 words? (Score:2)
Micro$oft is very evil.
embarrassing what qualifies as a programmer (Score:4, Insightful)
"This is what we live with in C. This is why we don't like it."
It is not, it's what is lived with in a codebase, C has nothing to do with it. Also, there is nothing about an approach mandated by one language that cannot be implemented in C, Rust creators have not made anything that kernel developers cannot otherwise do.
It is sad what programmers have become that cause claims like this to be made.
"With CI [Continuous Integration] bots enforcing builds ..."
The battle is already lost.
"They realized all input is evil. You have to validate all input."
No. Depends on where the input comes from. Hard to have respect for this guy, regardless of what he is alleged to do.
Re: (Score:3)
"what he is alleged to do"
WTF? that's like saying Linux is "alleged" to have been named after Linus Torvalds
Re: (Score:3, Insightful)
It is not, it's what is lived with in a codebase, C has nothing to do with it. Also, there is nothing about an approach mandated by one language that cannot be implemented in C, Rust creators have not made anything that kernel developers cannot otherwise do.
C has everything to do with it. C requires that programmers be infallible. They're not. They never have been. They never will be.
Rust's designers understand that programmers are human and will always make mistakes so the language allows and even requires building safe zero-cost abstractions that allow the compiler to check for huge swathes of common mistakes. Rust isn't the first language to do that, by any means, but it's the first language that (a) does it consistently and thoroughly (C++ fails this
Re:embarrassing what qualifies as a programmer (Score:4, Insightful)
The reason is that even though he has been programming in C for 20 years or more in the kernel, he never sat down and asked himself, "How do I avoid memory bugs in C? How do I avoid bugs?" It wasn't until he started using Rust that he even began approaching that question.
So his code is going to have plenty of other bugs, simply because he's never asked himself the question, "How do I avoid bugs?" No language is going to save him.
Re:embarrassing what qualifies as a programmer (Score:4, Insightful)
You know what improves code quality? Process improvements.
You know what doesn't improve code quality? Telling people that they suck. It's pointless and immature.
Re: (Score:2)
Re:embarrassing what qualifies as a programmer (Score:4, Interesting)
As someone who has had several 5-minutes-of-fame CVEs attributed to me, I can assure you that all programmers suck, particularly those wielding C. You're no exception. Neither am I. Despite 20 years of experience, and many hundreds of thousands of lines of C to my name doing work right now around the world.
I'm far from a Rust fanboi- I find the syntax revolting. I know a lot of that is personal taste, and that I'm old, and that's not going to change.
All that being said, it's simply undeniable that all code is going to have bugs, and a language that makes certain classes of bugs impossible is going to have less.
Remember, what matters are facts- not feelings.
Re: (Score:3)
The OP was giving you facts.
In other domains when performs keep happening, the solution is process improvements, to mitigate the fallibility of humans.
Programming isn't special here and neither are programmes. We don't yell at pilots that they suck, we now have extensive process improvements and planes are pretty safe. In much of Europe, if a road is dangerous, we generally try and fix the road to be less safe, not the road users which is why much of Europe has much safer roads than America which does not f
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
It is very typical of an American to pick the worst instance of anything they can find in order to prove they're better than the very worst thing you can find! Good for you!
Meanwhile you have roads that are more dangerous than anything in Western Europe. I look forward to your excuses as to why this is the case.
Re: (Score:2)
"I've seen the pictures" says another American who figures using the internet amounts to actually living life, going places, being less of a moron.
Re: (Score:2)
While he's written a fair bit of code, he's mostly been a maintainer for a long time.
There are ~5000 Linux kernel devs representing over 300 corporations.
Do they all suck as much as GKH? Then why would anyone adopt Linux?
Hint: Linux world domination happened quite some time ago.
Re: (Score:2)
Do they all suck as much as GKH?
No, they don't. Some are worse. Some are better.
Re: (Score:2)
Some are worse. Some are better.
That's applies to everyone, in every field.
GK-H has been deeply involved with Linux kernel development for TWENTY years.
If he sucks so much then so does Linux sucks and i would think you must scrupulously avoid using it in all circumstances.
Re: (Score:2)
Sounds like you're speaking to yourself.
GK-H has a considerable body of work.
Where's your "factual analysis" of his suckage compared to other professional C programmers or kernel devs?
Re: (Score:2)
Re: (Score:2)
i already have. if GK-H sucks as much as you imply, then his code would suck and so would Linux code in the systems he oversees.
Re: (Score:2)
Re: (Score:2)
You clearly didn't read my comment.
Try doing some "factual analysis" on GK-H's body of work and get back to us.
We're not interested in your emotional reaction to what he said at a talk,
Re: (Score:2)
he never sat down and asked himself, "How do I avoid memory bugs in C? How do I avoid bugs?"
Of course he asked himself those questions. The problem is that the answer is "I can't. I can do some things to try to reduce their occurrence, but C is fundamentally not designed to make avoiding them possible".
Re: embarrassing what qualifies as a programmer (Score:2)
Re: (Score:3)
Fa
Re: (Score:2)
Rust has added a process which makes the language handle the bit humans are really bad at handling. The bit where even the most excellent programmer makes easy to miss mistakes just by having a bad day. This process can't be implemented in C.
It's sad what the peanut gallery has become that cause claims like this to be made.
And yes. All input is evil. Exactly all. No exceptions.
Re: (Score:2)
This process can't be implemented in C.
Bullshit, all the memory safety could be implemented with some set of factory and clean up functions that are always the 'owners'. All the bounds checking could be implemented with some macro version/replacements of C's control flow constructs.
There is literally nothing stopping you from doing everything RUST does in plain C, except for the fact it would result in a confusing syntax and nobody would want to work on your project.
Ditto you could certainly build just about all of C++ in C as well, in fact the
Re: (Score:2)
This process can't be implemented in C.
Bullshit, all the memory safety could be implemented with some set of factory and clean up functions that are always the 'owners'. All the bounds checking could be implemented with some macro version/replacements of C's control flow constructs.
Ah, the "Of course we can do this if only programmers always remember to do X, Y and Z" argument.
This is exactly the point. Rust encodes those safe practices into the language and has the compiler enforce them. No one is arguing that it's not possible to write safe, correct C code. Only that humans are incapable of doing it at scale.
Re: (Score:2)
This is simply not true. You cannot write C in such a way to perform all the memory safety and type checks that Rust does at compile time. That would require changing the C syntax and semantics. Fine idea, but if you do that then that new language will not be C any more and it will likely look like Rust.
Re: (Score:3)
It is not, it's what is lived with in a codebase, C has nothing to do with it. Also, there is nothing about an approach mandated by one language that cannot be implemented in C, Rust creators have not made anything that kernel developers cannot otherwise do.
Broadly speaking, no this isn't correct.
From a very narrow perspective there's some truth: C is Turing complete so you can do anything in it you can do in another language. But that's also an argument in favour of writing the kernel brainfuck, Malboge or
Re: (Score:2)
I can't remember the last time I encountered a commercial project in C other than tiny firmware.
I'm even seeing tiny firmware moving to Rust. no_std noalloc Rust is actually a pretty good fit for that environment, especially since a lot of tiny firmware code absolutely, positively must not crash, ever. Rust's memory safety plus the no-panic crate get you about as close to that as possible without formal methods. The biggest remaining gap is stack overflow. flip-link is a pretty good tool for that; it doesn't keep you from blowing the stack, but it makes stack overflows a hard, immediate crash rath
Re: (Score:2)
What's the benefit of Rust here though? (Score:5, Insightful)
If you've got the AI tools to tell you how you screwed up with C, why do you need Rust? Just fix what the LLM says you broke. Now you have the speed of C without the bugs. It ought to be easy to find that class of error, right?
Re:What's the benefit of Rust here though? (Score:4, Insightful)
Better yet, the LLM can just write the secure C code in the first place.
If Mythos is so great, why not close the loop?
Re: (Score:2)
If we're going to appeal to religion, we might as well pray for it to write us a linter to solve this problem once and for all.
Re: (Score:3)
The problem is that time between the AI tool discovering a bug and the release of the patch, there's a bunch of panicked work by the developers and a time where the vulnerability is exploitable without an available patch. So if they can avoid several classes of errors and those are most of what the AI are finding, there's a bunch of work saved.
If it was just the developers using the AI tools though and the patch notes weren't open, then you'd more correct.
Re: (Score:2)
Re: (Score:3)
For existing code in the QA he said leave it be and it's better to fix.
For new code, he's recommending Rust and the advantage he talks about is that it makes the code more maintainable by people. And one thing that every AI coding talk I've seen agrees on is that what makes code more maintainable by people also helps AI and vice versa.
People and AI both have limited attention and memory. The less context necessary the easier it is to evaluate safety.
Another thing not in the summary he touches on is hardwa
Re: (Score:2)
If you have access to a God-tier LLM that you can rely on to find every bug, I think that could work.
However, I don't think anyone in the Linux community is ready to trust LLMs to that extent just yet. Not only are they quite fallible, they are also non-deterministic -- so if you ask your favorite LLM to find the bugs in the code, and it doesn't find any, and then you feed it the exact same prompt again, it might find some on its second attempt. So how do you know when to stop re-asking?
LLMs are currently
Re: (Score:2)
So how do you know when to stop re-asking?
Why did the Irishman run a bug-checking LLM over his code before release?
To be sure
To be sure
To be sure
If it's still getting inconsistent results when run multiple times over the same code, the LLM needs more work.
Re: What's the benefit of Rust here though? (Score:2)
âoeThe car wash to raise money for the bake sale has been canceled due to confusionâ
Re: (Score:2)
Why have an LLM tell you it thinks you fucked up when you can have the compiler not allow you to make the fuck up in the first place?
As always (Score:3)
Everything decays to Rust [9cache.com].
Re: (Score:2)
if any of the other programming languages were good enough, the Law of Rustification would not exist.
that said, Zig apparently is showing great potential as a Rust alternative but still some way distant from a 1.0 release
Other quotes from talk. (Score:3)
To balance out OP's selective quoting to avoid people strawman-ing his argument as a fanatic who can't balance risk:
"No, we don't want [rust] 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."
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..."
Expected article in 3..2..1.. (Score:2)
"AI will save Linux from Rust"
Rust really does make a difference (Score:2)
After doing some heavy low-level C coding for many years, I recently decided to look at Rust and see what it's all about. It really is a huge improvement over C.
With C, you need to understand the capabilities of the hardware and low-level operating system features. Shared memory, locks, semaphores, basic memory management, and, of course, pointers for everything.
With Rust, a deeper understanding of how the OS works really helps. The heap and stack for function calls and passing parameters, concurrency, a
Re: (Score:2)
C has evolved. but not enough. too much resistance.
What Rust needs to do is pressure C to evolve features that negate the need for Rust. AI can make the compiler smarter if you limit it's reach so it's not generating code and replacing compiling. The fact C is so stubborn that it is under real threat of becoming irrelevant and only an entrenched legacy language is a bad sign. Cobal on the other hand, has a stronger case for being relevant but it's been pushed out so it's not like rationality is what guides
Re: (Score:2)
With C, you need to understand the capabilities of the hardware and low-level operating system features. Shared memory, locks, semaphores, basic memory management, and, of course, pointers for everything.
So you need to have a computer science degree?
Rust will bring world peace (Score:5, Funny)
We should allow for programming languages to be awarded the Nobel Peace Price.
If Henry Kissinger can get a Nobel Peace Price, Rust should also be able to get one because everything is better with Rust.
I'd wish that someone would have pointer out that Visual Basic doesn't have pointers so we could have had Linux kernel support for it.
Re: (Score:2)
cURL and libcurl are written and C (Score:2)
Rust and AI in the same article (Score:2)
I can't believe Rust and AI were mentioned in the same article and Slashdot didn't go down. I only see about 50 or so, "not on my lawn", "damn kids messing with technology, nothing wrong with the old ways" comments.
AI will save Linux from Rust! (Score:2)
How much is Rust now (Score:2)
The kernel is what, 3% rust, 98% C?
It's still 0% Zig so that's not great.
Re: (Score:2)
It's still 0% Zig so that's not great.
Minimal justice, if we want to split hairs.
Re: (Score:2)
That being said, LinuxBugs - CMemBugs + RustBugs < LinuxBugs.
Re: (Score:3)
Re: Rust Can't Even Save Linux from Vulnerabilitie (Score:3)
Re: Rust Can't Even Save Linux from Vulnerabilitie (Score:4, Informative)
Unfortunately not.
All programmes write bugs, not all programmes believe they do.
Re: (Score:2)
Do you claim to write no bugs?
Re: (Score:2)
Re: (Score:2)
All of them? How do you know?
Re: (Score:2)
Re: (Score:3)
I assume you're referring to formal verification of a particular program.
You can't prove all software. That's literally saying the halting problem is solvable.
Formal verification of all software written would drop the world's aggregate code output to a few lines per day.
Of course programmers should avoid bugs. However, unlike whether any arbitrary program will halt, your statement that any programmer that doesn't isn't is provably false.
Re: (Score:2)
Ask yourself that question everytime you find a bug in your code. Ask yourself, "How can I avoid making this mistake in the future?"
Re: (Score:2)
Moreover, this is what I think of you: https://www.youtube.com/shorts... [youtube.com]
I think that of you, because you've put tremendous effort into justifying why you shouldn't reduce your bug count.
Re: (Score:2)
The worst bugs are contextual misunderstandings. Technical help can't avoid this. It's in the same world of legal contracts and laws; tons of problems without technology, it's a human problem. Specifications issues, communication issues, understanding, lack of predictability, foresight, experience etc. add in technical issues and it gets worse but removing all tech issues the rest still remain. The more complex the tasks you need to automate makes for more problems; you can force multiply but then you free
Re: (Score:2)
Re:I don't currently use Rust (Score:5, Insightful)
Just to point it out, in case people drink the kool-aid.
Just be cause "Rust does this thing better" does not mean you should always use Rust instead of C. You should always be using C when performance matters. Not Rust, not C++. If anything, C developers should be always using /Wall or /W4 and then treat all warnings as errors with /Werror . Many MANY projects out there have thousands of warnings a lot of then dealing with uninitialized memory, integer/floating point casts, and string lengths.
Realistically, string handling sucks in C because of the baggage of ANSI C, as wchar_t makes things horrible to debug.
The thing that would make C/C++ code safer from the start to implicitly check the length of variables, instead of having to pass the length.
All post-unicode languages such as Rust, Javascript and Python (not PHP or Perl) handle their strings internally as unicode, thus you don't actually need to know the length of the string to pass to it. In C is a UTF-8 string have a BOM? Does it use Windows, Mac or Unix line endings? you have up to three additional non-printable characters when dealing with unicode. Then there is Windows which is an additional special hell because it's wchar_t is UTF-16 in visual C but UTF-32 in GCC. Yet the vast majority of software out there only wants to deal with UTF-8.
If C and C++ natively did UTF-8, a good chunk of mistakes would not happen. Pointer nonsense not withstanding, most of the mistakes in C could probably be tracked by an AI linter and OSS projects could just fix things instead of publishing code that would fall under treating all warnings as errors. It's the pointer stuff that trips up people who don't understand the underlying assembly language code it would make. So people not familiar with C or ASM will constantly use variables that use the local registers rather than the ram address, and then wonder why the compiler complains about stack space.
Fun fact "the switch" statement is a heavy use of the stack space, because the compiler is unwrapping this to a series of "jump if equal" which is equal to "if" statements. This is the purpose of making functions as small and single-purpose as possible and antithesis of C++ classes. This is why you don't use C++ in performance code.
Rust seems to aim to be "better C" but doesn't necessarily do so since it technically runs on the C runtime. I think Rust might be fine to use in things outside of kernel space, but it seems like it might be expensive to use in the kernel/driver space.
Meanwhile, Nvidia, AMD, Razer, and Logitech are out there making "Driver" bundles that are full on chromium embedded frameworks , going in much the wrong direction. These companies have stopped caring.
Re: (Score:3)
Realistically, string handling sucks in C because of the baggage of ANSI C, as wchar_t makes things horrible to debug.
The thing that would make C/C++ code safer from the start to implicitly check the length of variables, instead of having to pass the length.
That's why basically everything with a finite length in rust is a fat pointer. Even strings. Not null terminators to maintain compatibility with PDP-11 assembly -- just fat pointers.
Also, you can't make C++ safer...Just forget about it. 9 days ago, Bjarne Stroustrup claimed he hasn't made any mistakes with memory management in years, and he's got it in his head that modern C++ is memory safe. By memory safe of course, he isn't referring to temporal safety, he isn't referring to data race safety, he isn't re
Re: (Score:2)
Re:I don't currently use Rust (Score:4, Informative)
I'm not disagreeing with your analysis of pointer problems in C here, but most of your Unicode examples have nothing to do with C/C++. A BOM is a persistence concept, not so much an in-memory one (of course, you have to read files into memory and then decide what to do). More generally, any language that reads a text file needs to know what encoding was used - it is a lousy assumption that it is UTF-8 (and yes, the user/programmer has to tell the program as it isn't possible to deduce it reliably).
"Handling strings as Unicode"... just look at this link. Unicode is a big mess. Look especially at the question of string length which is pertinent to language handling. The Absolute Minimum Every Software Developer Must Know About Unicode in 2023 [tonsky.me]. The three languages you used as an example return different answers for the same string.
The mess has to do with the history of Unicode more than the history of any of the languages trying to deal with it. Unicode started out as 16-bit only (not UTF-16) and this is the era when Windows defined its API (which uses 16-bit strings), so that's what the API looks like. Unix started with ASCII, so the API is 8-bit - which essentially by default becomes (implicitly?) UTF-8.
I also doubt that "most" software wants to handle strings as UTF-8. There is an awful lot of Java/C#/Javascript code that natively uses UTF-16 strings (or sadly lots of programmers probably assume UCS-16). I think Python strings are also 16-bit. I realize that the tendency is to use UTF-8 in more and more places, but that isn't the same as "most software".
Re: (Score:2)
The way a language runtime stores unicode strings in memory is a different thing from the way the language interacts with byte data in the world. Python's approach is to treat unicode strings as essentially arrays of unicode code points. Slicing is all done based on the array position of the unicode code points. The way they are stored in memory is irrelevant to the programmer and abstracted away, except that the programmer still has to be aware of unicode's many warts such as pairs..
Under the hood Pyth
Re: (Score:2)
Perhaps it ought to... but it is worth the pain. There is a lot of good information in the article.
Re:I don't currently use Rust (Score:5, Informative)
If performance matters then Rust is perfectly fine. Rust generates code akin to that generated for C or C++. Heck it is using the same LLVM code generation as clang. We now this is true from many benchmarks comparing the languages and many real world examples.
Re:I don't currently use Rust (Score:5, Interesting)
You should always be using C when performance matters. Not Rust, not C++.
You clearly haven't written a significant amount of Rust (or C++) and then disassembled it to examine the output.
The thing that would make C/C++ code safer from the start to implicitly check the length of variables, instead of having to pass the length.
You mean, what Rust does.
In C is a UTF-8 string have a BOM?
Is a C string even UTF-8? You have no idea. The *only* thing you know about a C string is that it has some bytes and (you hope!) a NUL terminator.
If C and C++ natively did UTF-8
You mean, what Rust does.
It's the pointer stuff that trips up people who don't understand the underlying assembly language code it would make.
It's also the pointer stuff that trips up people who do understand the underlying assembly language code.
Fun fact "the switch" statement is a heavy use of the stack space, because the compiler is unwrapping this to a series of "jump if equal" which is equal to "if" statements.
Only if your compiler sucks, which hasn't been the case for a very long time. Back in the late 80s when I started writing C, compilers already optimized switch statements into binary searches of the target space. By the early 90s I'd encountered a couple of compilers that optimized them into extremely efficient hash tables, making them both faster and more compact. In the 2020s compilers are downright wizardly at optimizing these things.
This is actually really important for Rust, because Rust's type-safe-union enums strongly encourage heavy use of switches. Many cases that require vtable-based polymorphism in C++ (or structs of function pointers in C) end up as highly-optimized switches in Rust. You can do vtables in Rust, too, but they're strikingly less common than in C++ and even than in many common C styles.
This is the purpose of making functions as small and single-purpose as possible and antithesis of C++ classes.
Good C++ classes use functions that are as small and single-purpose as possible. You can write crap code in any language. You can write slow code in any language.
Rust seems to aim to be "better C" but doesn't necessarily do so since it technically runs on the C runtime.
This doesn't follow at all. Using the C runtime doesn't preclude being a better C, at all. The problems with C have very little to do with its runtime. C's problems are all about the lack of bounds checking, lack of dangling pointer checking, lack of thread synchronization checking. Note that in Rust the last two things are done entirely at compile time. It's like if "-Wall -Werror" got 1000 times smarter. Not because the compiler is smarter but because the language semantics don't require the compiler to allow a lot of potentially bad stuff.
It is true that sometimes Rust is too restrictive, disallowing provably safe code. Just yesterday, I couldn't convince the borrow checker that a function was safe without breaking a hashmap lookup into two steps. I actually considered using a small unsafe block to avoid the extra lookup. I decided against it, but this raises two points: First, in Rust if you need to you can always discard the protections (though note that even "unsafe" blocks are more restrictive than"-Wall -Werror") and drop down to a C style, or even assembler if you need to. Second, and more importantly, Rust points out when you're doing something potentially risky and forces you to think hard about it. C just lets you do it... even with -Wall -Werror.
I think Rust might be fine to use in things outside of kernel space, but it seems like it might be expensive to use in the kernel/driver space.
Rust is fine for both, though when using in the kernel, drivers or on
Re: (Score:2)
breaking a hashmap lookup into two steps.
Have you used the map.entry(&T) methods? i.e. or_insert, or_default, etc. Basically, if the entry isn't already initialized, it does so, then yields either what you specified to insert, or the default. Those ended up solving all of my borrow checker issues with hashmaps. A lesson I learned very early in my rust days:
https://stackoverflow.com/ques... [stackoverflow.com]
They also make it much easier to to deal with the "vector inside of each hashmap entry needs to be initialized" situation a hell of a lot easier than you've
Re: (Score:2)
Yeah, that is a nice approach in many cases.
My problem was different, though. My problem was that the function needs to return a &mut to the map value, and I also needed to take some other action that involved a map lookup if the map entry wasn't present. The two actions (return map entry reference and perform another possibly-mutating action on the same map if the searched-for map entry wasn't present) were in two different match arms, so there was no mutable ref being held on the map in the value-
Re: (Score:2)
Small and scoped function/procedure/method/put-here-how-you-reuse-code is a must have on any language.
Re: (Score:2)
... have stopped caring.
This... I feel like this is just the pervasive world we live in recently. I want to literally turn off the internet, AI, everything, and just go read my "Best Practices in C" book alone in the woods and just forget about how messed up software has gotten in the 15 years I've personally been around the industry and can't imagine how those who've been around decades longer even feel about all this crazy business at this point.
Re: (Score:2)
Nonsense. Modern C++-isms often result in extremely fast, optimized code. For some good examples, see this presentation about using C++17 to generate fast 6502 code: https://www.youtube.com/watch?... [youtube.com] Of course this presentation is also a good one to show you why you'd rather not use C++17 at all. But for reasons other than efficient and fast binary code.
Re: (Score:3, Insightful)
This is why C code is bad, because C programmers never ask themselves, "How do I not leak memory?
WTH sort of C programmers have you been talking to? Yeah, you should get those guys on Rust as soon as possible.
Re: (Score:2)
This is why C code is bad, because C programmers never ask themselves, "How do I not leak memory?"
Another way to phrase that would be, "This is why C code is bad, because C programmers are expected to understand the rules about how to not leak memory, but there is no mechanism to enforce that requirement".
Re: (Score:2)
Re: (Score:2)
Seasoned C programmers create memory bugs all the time. I mean, the idea that "experience" leads to perfect code is bananas. There's a reason why static analysis is used in any serious environment. Rust just makes that part of the language without an annoying about of tooling/pipeline cruft.
Re: (Score:3)
C isn't "bad". It is a brittle language for sure, but the purpose behind C isn't to hold your hand, it's to be a slightly higher level abstraction of assembly to make it portable. C expressly leaves code robustness up to the developer. Which is ok, the caveat being that you need to really be careful with what you're doing, because it deliberately has only very few guard rails (you can't, for example, mutate the size of a variable, only its value, but beyond that you can mangle it however you want, just like
Re: (Score:2)
The problem is he had never put much thought into how to actually manage memory in a reasonable way in C. This is why C code is bad, because C programmers never ask themselves, "How do I not leak memory?"
Honestly this reads like you've never worked with real programmers.
Re: (Score:2)
Re:I don't currently use Rust (Score:4, Informative)
In theory, it can, but in the real world it just doesn't. Rust aimed for C++ level performance, but ended up being within a hair of C in real world situations. C is the benchmark because it's generally the fastest high level programming language aside from fortran, though C saw broad adoption that fortran did not, basically because of Unix, with C being used to make (previously assembly) Unix portable to more hardware architectures. C++ came around at a time when fully object oriented programming seemed like a good idea, even though inheritance later proved to be a terrible idea, and to fix some problems with inheritance, C++ added...multiple inheritance...which turned out to be an even worse idea.
Re: (Score:2)
Same thing with idiots who are against self driving cars. "Just get people to drive better, we don't need it" .. "Eat healthy we don't need a cure for cancer, heart disease."
Morons.
Re: (Score:3)
Re: (Score:2)
I haven't been around a flood area with it, but my Tesla definitely braked and maneuvered to avoid a squirrel .. at least at low speed. It also respects road closure signs/barriers.
I never heard of Tesla having a flood issue, but if that's a thing I'm sure it will quickly be fixed as water or wonky surface isn't exactly something hard to identify.