"Participants got behind the wheel of a driving simulator equipped with everything you’d find in a real car – from the steering wheel to the pedals and dashboard. A large touchscreen, similar to those found in newer vehicles, allows for music to play and text messages to come through. Three oversized monitors provide 180 degrees of visual coverage to create a realistic, immersive driving environment."
Seems pretty clearly a simulator, they use that word several times.
Still a simulator is not going to replicate the mind set of actually driving a vehicle. It probably helps a little bit that the participants are high, but still it’s not even close.
To be even fair-er, it wasn't actually memory unsafety, it was "just" unsoundness, there was a type, that IF you gave it an io reader implementation that was weird, that implementation could see uninit data, or expose uninit data elsewhere, but the only readers actually used were well behaved readers.
Thats kinda the problem, there are concepts in rust that don't have equivalents in other common languages. In this case, rust's type system models data-race-safety: it prevents data races at compile time in a way unlike what you can do in c or c++. It will prevent getting mutable access (with a compile time error) to a value across threads unless that access is syncronized (atomics, locks, etc)
And from what I can see, rustlang mutability is also a type system construct? I.e. it assumes that all other code is Rust for the purpose of those checks?
> rustlang mutability is also a type system construct?
Yes
> I.e. it assumes that all other code is Rust for the purpose of those checks?
Not exactly, it merely assumes that you upheld the documented invariants when you wrote code to call/be-called-from other languages. For example that if I have a `extern "C" fn foo(x: &mut i32)` that
- x points to a properly aligned properly allocated i32 (not to null, not to the middle of un-unallocated page somewhere)
- The only way that memory will be accessed for the duration of the call to `foo` is via `x`. Which is to say that other parts of the system won't be writing to `x` or making assumptions about what value is stored in its memory until the function call returns (rust is, in principle, permitted to store some temporary value in `x`s memory even if the code never touches x beyond being passed it. So long as when `foo` returns the memory contains what it is supposed to). Note that this implies that a pointer to the same memory isn't also being passed to rust some other way (e.g. through a static which doesn't have a locked lock around it)
- foo will be called via the standard "C" calling convention (on x86_64 linux this for instance means that the stack pointer must be 2-byte aligned. Which is the type of constraint that is very easy to violate from assembly and next to impossible to violate from C code).
That it's up to the programmer to verify the invariants is why FFI code is considered "unsafe" in rust - programmer error can result in unsoundness. But if you, the programmer, are confident you have upheld the invariants you still get the guarantees about the broader system.
Rust is generally all about local reasoning. It doesn't actually care very much what the rest of the system is, so long as it called us following the agreed upon contract. It just has a much more explicit definition of what that contract is then C.
Also we can (in 2024 Edition) say we're vouching for an FFI function as safe to call, avoiding the need for a thin safe Rust wrapper which just passes through. We do still need the unsafe keyword to introduce the FFI function name, but by marking it safe all the actual callers don't care it wasn't written in Rust.
This is fairly narrow, often C functions for example aren't actually safe, for example they take a pointer and it must be valid, that's not inherently safe, or they have requirements about the relative values of parameters or the state of the wider system which can't be checked by the Rust, again unsafe. But there are cases where this affordance is a nice improvement.
Also "safe" and "unsafe" have very specific meanings, not the more widely used meanings. It's not inherently dangerous to call unsafe code that is well written, it's really more a statement about who is taking responsibility for the behavior, the writer or the compiler.
I like the term "checked" and "unchecked" better but not enough to actually lobby to change them, and as a term of art they're fine.
Yes. Just like C++ "const" is a type system construct that assumes all other code is C++ (or at least cooperates with the C++ code by not going around changing random bytes).
As far as I can tell, ANY guarantee provided by ANY language is "just a language construct" that fails if we assume there is other code executing which is ill-behaved.
"The common ground is that I have absolutely no interest in helping to spread a multi-language code base. I absolutely support using Rust in new codebase, but I do not at all in Linux." https://lwn.net/ml/all/20250204052916.GA28741@lst.de/
That doesn't sound like he's only talking about in his area to me
I'm just parsing the thread but it seems that changes to the C api can break the Rust bindings.
This leads to two situations: the C maintainer has to also update the Rust binding, or the patch has to wait for a Rust capable maintainer to fix them up.
For the first solution, the C maintainer is claiming he has enough work on his plate just keeping up with the C code that he doesn't want to work on Rust. He also believes it is unfair to force every C maintainer to learn enough Rust to keep their integration points working.
For the second solution, the C maintainer is pointing out that Linus has a history of refusing to merge C patches that break Rust builds. So even though the Rust advocates promise they will handle all of the Rust stuff and they are OK with their stuff being broken after C changes until they get around to fixing it, Linus doesn't seem to actually allow for this in practice.
I can see the maintainers point. Sooner or later Rust bindings on critical systems will be essential and changes to the C code will be gated on changes to the Rust code. It is a fantasy of the Rust maintainers that they will have to shoulder that entire burden. But even if they did, it would give them some pretty hefty leverage over the C maintainers in those essential cases. And it also introduces a requirement that someone with enough Rust and subsystem knowledge is even available for the job. People making promises today may disappear tomorrow, leaving the maintainer with an essential binding to a language he doesn't want to support.
edit: as has been said elsewhere, Linus could make some of this go away by committing to let the Rust builds break. I don't know if that could be done in a way that wouldn't be a de facto fork.
> Linus could make some of this go away by committing to let the Rust builds break.
Linus already did that. This is the state of things today. C code is allowed to break the Rust, and it's the Rust for Linux people's responsibility to get it working again, not the C folks.
I'm just an interloper and only going on the linked thread, but there are specific patches that missed merge windows due to Rust build breaks. The patches referenced are claimed to be exceptions but I can understand the fear. Linus is saying one thing but making exceptions in some cases. As Rust becomes more and more integrated into core Linux systems those exceptions may become more frequent and may eventually become the rule.
To be fair, I think another valid solution to this problem is just to bite the bullet and tell the grumpy C developers to deal with it. At some point the fallout from an exodus of grey beard Linux maintainers will actually be less than fighting this battle. As many point out, they are going to exit the project one way or another eventually.
> The patches referenced are claimed to be exceptions
From what I understand, this is correct, or at least that is, this was a build system bug that caused accidental breakage, not a deliberate change in the policy that the kernel must be able to be built with Rust support turned off, and that that is the build that matters. Exceptional in a "rarely happens" sense and not a "deliberate choice to create an exception to a rule" sense.
This entirely depends on the supposition that there are more new kernel developers who want to, and are able to, use Rust then C.
I don't think this is proven: what we have is a specific group of Rust developers, but they are there by virtue of that group existing. There are numerous more kernel contributors today who work in C, and since the greybeards are happy to keep up the work it's not like anyone else is going to easily step in to replace them (since it would be a coup not a handover, if they didn't actually want to step down).
An equally plausible future is some such Rust mandate happens, you drive off the existing C developers, then it turns out the Rust developers aren't actually numerous enough or committed enough (or even good enough at long term project social management) to keep the project going and it dies (or forks into CLinux or something).
Linux itself was a "hobby project" which ultimately succeeded because it did the work which needed to be done, while everyone else was still completely sure the microkernels were the way of the future.
No, the point is nonsense. Rust is a consumer of the APIs just like every other driver / subsystem is. Any change to the C APIs would likely require collaboration with those other maintainers no different than Rust. And CH would be immediately shut down if he tried to roadblock some random driver that needs DMA purely because he doesn't want the existence of that driver to "increase his workload".
I think you are using inflammatory language by calling the point nonsense.
As an outside observer, literally no skin in this game, I can see his point. If his C code changes breaks other C code then he is at an advantage compared to if his C code breaks a Rust binding or Rust drivers. The degree to which this adds to his burden of maintenance is up to him to decide.
The kernel is extremely complex. He very likely still needs to work with other maintainers if his code breaks their code. In this case he has LESS work to do, because the R4L developers own all fixes to Rust code, and he is free to break them, and they have to clean it up themselves.
The complexity of kernel isn't relevant, unless your point is that the kernel is already so complex that maintainers shouldn't advocate against new and significant complexity?
As for less work, that is alternative two from my original post which states the maintainer now has to wait for someone else to do the work or risk his change being stalled (worse case: indefinitely). It doesn't matter if the R4L team promises that they are OK with broken Rust code since the only person whose decision matters is Linus. Until Linus clarifies his stance on broken Rust builds the promises of the R4L team are promises that they are literally incapable of delivering on.
But it does. He has to notify R4L of what his changes were and how it broke the Rust driver. Even if he didn’t, he will still be contacted for information regarding these things.
How is that different from any C driver currently in existence? Notifying API consumers of what is changing and how and answering the occasional is absolute table stakes for any software developer and throwing a tantrum about that is incredibly juvenile.
Maintainers come and go, languages come and go. C will never go away and everyone working on kernels knows C, so there's a certain labour pool and skillset that will always be available that doesn't necessarily apply to Rust. That's even setting aside any technical issues, like bugs creeping up in the language interoperability layer, which obviously doesn't really happen if you're only using one compiler.
The R4L says they will make sure the Rust code is fixed when the C code is, and that's admirable, but the concern it means a developer now has to wait for that, holding up their work for release/submission. The bus factor is now on the R4L team.
Meanwhile, everyone involved in development for Linux already knows C.
Rust optimizes factorial to be iterative, not using recursion (tail or otherwise) at all, and it turns `factorial(15, 1)` into `1307674368000`: https://rust.godbolt.org/z/bGrWfYKrP. As has been pointed out a few times, you're benchmarking `criterion::black_box` vs `benchmark.keep` (try the newer `std::hint::black_box`, which is built into the compiler and should have lower overhead)
I updated the blog with full benchmark reproduction instructions, I also removed criterion::black_box altogether, and it resulted in no performance difference. Removing benchmark.keep from Mojo causes it to optimize away everything and run in less than a picosecond.
If you could show me a benchmark that supports what you're saying that'd be great, thanks.
Rust realizes the vector is never used, and so never does any allocation, or recursion, it just turns into a loop to count up to 999_999_999.
And some back of the napkin math says there's no way either benchmark is actually allocating anything. Even if malloc took 1 nanosecond (it _doesn't_), 999_999_999 nanoseconds is 0.999999999 seconds.
It _is_ somewhat surprising that rust doesn't realize the loop can be completely optimized away, like it does without the unused Vec, but this benchmark still isn't showing what you're trying to show.
On the other hand, to be fair, a device driver itself (even though it is represented as a "special file") does not need to have the notion of a file system built into it.
Seems pretty clearly a simulator, they use that word several times.