A lot of good stuff in there
A lot of good stuff in there
Posted Feb 15, 2025 4:45 UTC (Sat) by ebiederm (subscriber, #35028)In reply to: A lot of good stuff in there by khim
Parent article: New leadership for Asahi Linux
I came to the conclusion very quickly that for the kinds of code I typically write, I can not express it in safe Rust.
Not that we are talking much of a challenge. I have to think hard to find any of the data structures from my intro to data structures and algorithms that Rust can be implemented in safe Rust.
At which point I do my research and I see that Rust dropped the ball and it is possible to machine check the implementation of those algorithms. Rust just doesn't give me the tools I need.
I do a bit more research and realize that C has a lot of accidental/unnessary complexity C++ is off the charts. Rust isn't as bad as C++ but there remains a lot of unnecessary complexity. Which all matters because if we want to build aecure software. The kind where we can stand a server up on the Internet and start having to worry what happens when the uptime counter wraps because there hasn't been any security issues found in the software for years. Completely matters.
The more complex the foundation is the harder it is to analyze.
Which means Rust really isn't a programming language I desire to use. It complains because it can not understand my safely written code, and it complicates analysis of that code.
Rust seems an incremental step forward. But we are talking an incremental step forward from code that has been good enough for the last 25 years to exceed the reliability of bleeding edge hardware. I have stories.
That is C really is good enough to get the job done.
I have seen people make the case that Rust can get the job done too. I haven't seen much support for the notion that Rust does the job better. I am pretty certain if I were using Rust I would find it an over complicated clap trap that I have to continually fight to get it out of my way.
Posted Feb 15, 2025 5:28 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
I struggle to understand how you can reconcile these two statements. C has shown again and again and again and again and again and again that it's NOT possible to write secure non-trivial software in it. Pretty much every large network-facing product in C has seen its share of critical security issues.
> Rust seems an incremental step forward. But we are talking an incremental step forward from code that has been good enough for the last 25 years to exceed the reliability of bleeding edge hardware. I have stories.
What "reliability"?
Posted Feb 15, 2025 13:08 UTC (Sat)
by ebiederm (subscriber, #35028)
[Link] (3 responses)
I do not see Rust making it possible to do the above.
The Rust type system does not allow modelling what needs to be modelled to allow for data structures to be written in safe Rust. For me it is like working with epicycles in an Earth centered solar system model, when what we need are ellipses in a sun centered model.
It is a lot easier to show an ellipse is correct because the model is simpler.
Although honestly I don't think Rust has managed to be even as good as epicycles were in astronomy. Rust just says: it is unsafe I give up.
If Rust only gave up on the implementation details of tricky things like RCU, and the fine details of spinlock implementations, sure. That stuff is hard. But into to data structures 101. That seems to push pretty much every pice of code I write into unsafe land.
So my first statement was about where I would like an operating system to be, and how I don't see Rust making it easy to get there
My second statement ( "C is good enough") is about practical utility. In the common cases. In the cases where nobody cares about security.
Try standing up to a boss who has a make or break the company feature they want to ship, and tell them what you are building on is implemented insecurely and it will be another year before the foundation has a proper foundation.
You say:
I will point out that every time it is some silly mistake. An off by one error, or not getting error handling quite right. Overall code paths that don't matter for what people are trying to do. Almost always a localized and simple fix will do.
Which is to say it isn't the hard stuff that C gets wrong, C simply does not give enough support to prevent errors in the easy stuff
Telling people what they have been doing for their entire career is hopelessly broken, is not a selling point especially when they know better. They know what they have been doing gets the job done.
To actually achieve secure software I can leave on the Internet for decades without updating, I am pretty certain that will require supporting statically verifying assertions about the code. As only machine validation can be thorough and patient enough to check every little corner case.
So far Rust makes some headway in that department but then it's type system sees an unsafe and bows out. I haven't seen anything in Rust beyond it's type system that can be used to catch the rare mistakes conscientious people make.
Posted Feb 15, 2025 13:26 UTC (Sat)
by mb (subscriber, #50428)
[Link]
Nobody claims that you can implement RCU or spinlocks in safe Rust.
>I will point out that every time it is some silly mistake.
In Rust most of these silly mistakes are impossible to do. That's the point.
>Almost always a localized and simple fix will do.
Not having to do a fix, because nothing is broken, will do better.
>Telling people what they have been doing for their entire career is hopelessly broken, is not a selling point
Sure. People tend to not like changes.
>They know what they have been doing gets the job done.
... with a steady stream of security issues.
>but then it's type system sees an unsafe and bows out.
unsafe blocks don't disable any of the type, borrow and safety checks.
>I haven't seen anything in Rust beyond it's type system that can be used to catch
Sure. But that's just because you didn't look. Not because they don't exist.
Posted Feb 15, 2025 21:43 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Which data structures Rust doesn't allow to be modeled (perhaps with a bit of `unsafe` inside the implementation)?
> My second statement ( "C is good enough") is about practical utility. In the common cases. In the cases where nobody cares about security.
No. C is not "good enough". It's downright dangerous. At this point, merely using C for new projects should be considered bordering on criminal negligence.
> I will point out that every time it is some silly mistake. An off by one error, or not getting error handling quite right. Overall code paths that don't matter for what people are trying to do. Almost always a localized and simple fix will do.
Yeah. And that's how we get airplanes crashes and nuclear reactor blowups. This attitude is just distilled nonsense and sheer arrogant ignorance.
The single greatest advantage in the safety science was the recognition that humans can't help but make mistakes, and that measures should be taken to make these mistakes impossible: LOTOs, automatic safety interlocks, etc. So every other engineering discipline (including the ones that are much younger than Computer Science) has adopted tools that reduce the possibility and the impact of "silly mistakes". Even non-engineering disciplines are doing that.
The latest advantage that drastically reduced the death rate in surgeries was not some kind of tricorder powered by AI, but simple checklists: https://en.wikipedia.org/wiki/WHO_Surgical_Safety_Checklist
Posted Feb 16, 2025 22:28 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
Do you have any existing examples of this actually happening in any language, nevermind C? Maybe Erlang-based deployments at telcos (depending on your definition of "update")? But I can't think of any C program that has been "on the Internet for decades without updating" while also being "secure". Unless maybe you're counting `/bin/true` as "on the Internet"?
And I agree that machine validation is required for further trust in software. But Rust is not only more easily tooled (because its source just has more information than C does), but *has* better tooling in almost every dimension that matters (sure, UBSan is "better" for C than Miri is for Rust given Miri's limitations, but its need for such a tool is also *far far* lower).
Posted Feb 15, 2025 11:58 UTC (Sat)
by khim (subscriber, #9252)
[Link]
How is it different? If course they can all be implemented in safe Rust. Just put all your data structures into array and use indexes. That's how we studied them when I was in school which only had access to some crazy micros with BASIC in ROM. What you can not implement in safe Rust is something that gives you the exact same beautiful and clear machine code that exist in your head. That's different issue. Are you sure? Why do you implement the exact same data structures again and again? What's the point? What happened do “don't repeat yourself” and code reuse? Yes, less complex languages are desirable… but only if they are expressive enough to provide safety guarantees. C and even C++ don't provide them. Rust does. It's as simple as that. After all BASIC is arguably simpler than C and yet kernel is not written in QB64 As long as you are using Linux that's impossible because even just security in kernel are found more often that we may like. Only if “all other things are the same”. In case of C and Rust they are not the same. Yup. That's what FORTRAN and COBOL programmers were telling themselves half-century ago. When structured programming debates raged. And then they were fired and replaced with Pascal and C programmers, and their ability to juggle complex GOTO-filled programs haven't mattered one jot. COBOL programming got vindication years later when banks needed to do something for their decades-old systems. FORTRAN programmers mostly had to leave programming completely. I interviewed few, when they tried to return to IT, years later, and were even willing to learn “new ways of doing things”, but my boss rejected them. Ironically enough over time strict restriction on “no GoTo ever” was relaxed a bit with MISRA C 2012 allowing forward goto and exceptions being nothing more than interprocedural forward gotos… but that happened years later. Initially rejection of unstructured control flow was implemented with almost religious fervor. Just like FORTRAN and PL/I were “good enough” half-century ago. They are still with us, but no new projects are written in them. The same would happen to C. The interesting questions are not if C would be replaced but what would it be replaced with – and if Linux would survive that replacement or not. Because when all that heat was generated in the 1970th… no one could predict that it would be C that would win the race, in the end. Not just reigning king, Pascal, was much more popular, but even Ada was, briefly, more popular than C! Then lawsuit happened that changed the course of history… something like this may happen in the future, still. For example if Apple would either be broken up or would collapse (which would free swift from it's shackles) then we may end up with the future where Swift and not Rust would replace it. Currently tremendous advantage of Rust lies with the fact that it was developed in Mozilla that's currently not financially capable of supporting and controlling it and thus it's the first contender for the C/C++ replacement. But like AT&T breakup, suddenly propelled C and C++ to the stardom… something like this could still happen to Swift, or, heck, even Carbon. Language development is fascinating area where technical capabilities determines losers while social dynamics determines winners. That's how we can say that C is doomed (it's simply technically not good enough to survive), while saying that Rust would replace it… looks more and more likely, but then in the middle of 1980th it looked as if Pascal would replace FORTRAN and COBOL… OSes (e.g. Apple's Lisa and Classin MacOS) and programs (most early Microsoft programs for PC) were written in Pascal – yet ultimate winners were C and C++ from AT&T.
Posted Feb 15, 2025 17:53 UTC (Sat)
by excors (subscriber, #95769)
[Link]
I'd agree that Rust is a poor language for introductory computer science. E.g. it doesn't closely match the pseudocode of CLRS (where much of the book is dedicated to complex and subtle mathematical proofs of correctness, which is antithetical to Rust's idea of mechanically-verified correctness; and the book doesn't care about concepts like ownership because it never deallocates anything, effectively assuming you have a GC). Java or Python would be a much better fit while you're working through a textbook like that. For recursive data structures (singly-linked lists, trees), Rust is quite cumbersome - you'd be better off with ML or Haskell. For learning how CPU hardware works, you'd want an assembly language (or maybe C-as-portable-assembly, keeping away from its rough edges).
Rust isn't meant for computer science, it's meant for software engineering. It's for when you've already learned the CS and you're trying to apply it in real-world codebases, where scalability and robustness and concurrency and non-asymptotic performance are much more serious challenges than how to implement yet another chained hash table from scratch. You'll just use std::collections::HashMap. In the very rare case you need a data structure that nobody else has implemented and published as a crate, then you can make use of your CS education and write it yourself; Rust probably makes it harder to get it right, but you only need to do it once, and then you can go back to the real software engineering that Rust makes a lot easier.
If you aren't doing software engineering, that's fine - there's plenty of programming (scripting, research, scientific computing, etc) where you'd probably get little benefit from Rust, and other languages will be better. But OS kernels and internet-facing applications are exactly where Rust's benefits are needed.
Posted Feb 15, 2025 20:08 UTC (Sat)
by roc (subscriber, #30627)
[Link]
A lot of good stuff in there
> That is C really is good enough to get the job done.
A lot of good stuff in there
> The kind where we can stand a server up on the Internet and start having to worry what happens when the uptime counter wraps because there hasn't been any security issues found in the software for years. Completely matters.
> C has shown again and again and again and again and again and again that it's NOT possible to write secure non-trivial software in it. Pretty much every large network-facing product in C has seen its share of critical security issues.
A lot of good stuff in there
If you can accept that then yes, C gets the job done.
>the rare mistakes conscientious people make.
A lot of good stuff in there
A lot of good stuff in there
> There is a different issue for me.
A lot of good stuff in there
A lot of good stuff in there
A lot of good stuff in there