Maybe make it aggregate the data over all commits and then use that as a learning opportunity to learn about tools like cargo-bench, criterion, cargo-flamegraph and other profiling and benchmarking tools and optimization techniques to see if you can speed it up, reduce its memory usage,…?
But also, there is a bit of a problem to adopt Rust. I think the memory model may prove challenging to some, but I do worry in this case that even if it was super simple, the existing C kernel devs would still reject the code due to it not being C and not willing to adopt a new language.
Perhaps the fact that Google is keen on Rust internally is part of what Ted Tso does not like about it ( he works for Google ).
Many outside the Rust community see the enthusiasm for Rust as overblown. Perhaps they think that pushing back on Rust to create a brake on this momentum is restoring the balance or something.
One thing I have noticed, when devs push back on inferior languages, they are able to cite all kinds of technical reasons for doing so. When they cannot come up with reasons, perhaps that is evidence that the language is pretty good.
Ted’s rant basically says “we have more code so we matter more and that will be true for a long time”. I agree with the assessment that this kind of blatant tribalism is “non-technical nonsense”.
The thing I don’t get in these discussions is that there are people who have convinced themselves that a language we came up with in the first 20 years or so of the industry’s existence is the pinnacle of programming language development and that all those newer languages are really completely equivalent in terms of outcome once you add up their up- and downsides.
There’s a long thread on Mastodon by the main Arm Mac Graphics dev for Asahi Linux. Perhaps one of the fastest developed and most stable graphics drivers ever made, thanks to a couple amazing developers but also very very much thanks to Rust. And one of the kernel devs flippantly calls it an “unmerged toy project” as if it’s not kernel devs’ fault that useful stuff and even small non-breaking improvements to existing systems are so incredibly hard to get merged. Not to mention that writing the entire m1 graphics driver in Rust ended up actually thoroughly documenting the DRM subsystem’s API for the first time as a side effect because everything the Rust code interacts with pretty much gets strictly defined within Rust’s type systems and lifetimes.
If I try to interpret the context, it could be C programmers just being negative to Rust because it is not C, that there is a conception of Rust programmers trying to enforce Rust on others, or that Rust programmers will break things.
Behind all the negative tone there is a valid concern though.
If you don’t know Rust, and you want to change internal interfaces on the C side, then you have a problem. If you only change the C code, the Rust code will no longer build.
This now brings an interesting challenge to maintainers: How should they handle such merge requests? Should they accept breakage of the Rust code? If yes, who is then responsible for fixing it?
I personally would just decline such merge requests, but I can see how this might be perceived as a barrier - quite a big barrier if you add the learning cliff of Rust.
From what I understood, the Rust devs weren’t asking to change the interface, only to properly document it, and asked the kernel devs to cooperate with them so that Rust for Linux doesn’t break without warning.
The Rust devs were trying to say they were fine if the Rust code ends up breaking, and they would take care of it. But they got talked over but the kernel dev.
rust
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.