With the Linux 6.13 kernel, Greg Kroah-Hartman described the level of Rust support as a “tipping point” for Rust drivers with more of the Rust infrastructure having been merged. Now for the Linux 6.14 kernel, Greg describes the state of the Rust driver possibilities as “almost at the “write a real driver in rust” stage now, depending on what you want to do.“
↫ Michael Larabel
Excellent news, as there’s a lot of interest in Rust, and it seems that allowing developers to write drivers for Linux in Rust will make at least some new and upcoming drivers comes with less memory safety issues than non-Rust drivers. I’m also quite sure this will anger absolutely nobody.
I did start using Rust at work for some media related stuff, and man…. it is bad.
I mean, it has some nice and modern stuff, but it tries to reinvent the wheel quite a lot, most of the way to write the code they changed from, now standard C/C++/Java/C#/etc is just HORRIBLE.
Why this “fn something(var1: String) -> returnType” instead of just “fn returnType something(String var1)”? except like, being different for being different? It makes you loose a lot of time with variable scope, that is an intewresting idea, but in the end just makes you use clone() in almost every function call parameters.
I wanted to like Rust, but, sorry, I hate it.
protomank,
A lot of people dislike the syntax. It’s more similar to modula/pascal than C. This probably stems from strong ties in academia, which isn’t inherently a bad thing but given that the majority of production work uses C derivatives, it seems like the choice of syntax was not helpful to rust’s popularity. IMHO rustlang being built atop a C-like syntax could improve the onboarding experience for a majority of developers with a C background.
@Alfman
I’ve come to the same conclusion, for the very technical applications the syntax makes more sense, it’s not hiding behind anything and a certain set of Devs will get it immediately, but it means for the wider public Rust is never going to be the next Python, at least not without a lot of AI help.
What would an ASM, C, Fortran or Pascal Dev find attractive if they came in from the cold without baggage to suddenly have Rust, D, Go, Zig or something else to play with, it’s an interesting question? It’s hard to be purely objective, because we all have baggage laden with our personal priorities.
Rust is basically a GC-less ML where they yoinked C++’s syntax and then filled the holes with borrows from Ocaml.
C++’s function syntax suffers from the Lexer Hack and the Most Vexing Parse? Patch in some bits of Ocaml syntax… and condense “fun” to “fn” while we’re at it.
C++ doesn’t have a pattern matching construct? Borrow Ocaml’s syntax.
std::optional
doesn’t exist yet? Borrow the Ocaml/Haskell/etc. construct that it’s cribbing off of and use Ocaml’s identifier names with adjustments to their capitalization for consistency.C++ doesn’t have a syntax for explicit lifetimes? Well, they’re a special type of generic/template parameter as far as the type checker is concerned, so nest Ocaml’s syntax inside the C++ syntax. (Yes, that weird
a'
is the Ocaml equivalent to<T>
and, in the Ocaml world, is probably meant to be interpreted through mathematics eyes as “a prime”.)I got to watch the process happen all over again when they brought in async/await and decided to break from the familiar and add the completely novel postfix non-method await syntax because they decided the benefits justified the added teaching burden.
ssokolow (Hey, OSNews, U2F/WebAuthn is broken on Firefox!),
It really doesn’t feel that way to me especially because declaring parameters and variables is all backwards. But regardless, it is what it is and I accept it.
I have yet to do this in rust, but I’m hopeful rust delivers the goods 🙂
https://rust-lang.github.io/async-book/03_async_await/01_chapter.html
While I’ve gotten used to writing event oriented state machines, async in C# has simplified a lot of my own program logic and it’s one of the features I miss the most in other languages.
Async in Rust is one of the areas people complain about being unfinished, since Rust follows a “release Minimum Viable Product, then improve” approach and async is much younger.
However, they’ve made significant progress recently (eg. the MVP for async fn in traits) and more is coming soon (eg. async closures should be stabilized in the new version coming out in February). They’ve also got improving async as one of the big things on the draft 2025H1 roadmap so async should hopefully become like the complaints about sync Rust before non-lexical lifetimes.
(people who started learning Rust after NLL landed don’t understand what people were complaining about because it Just Works… except for Problem Case 3 where it turned out to be much more difficult and they’re finally approaching the end of the major rewrite of the borrow checker to allow it to handle that situation. If something that “should work” fails borrow check, see if feeding
-Zpolonius
to the nightly-channel compiler makes it compile. If so, it’s Case 3 and will be fixed once they finish squashing regressions in the new implementation.)…and I just realized that, because I’m still recovering from a couple of days that I didn’t get much sleep, I wrote a’ instead ‘a and said “a prime” instead of “prime a” in my initial message.
Perhaps you can alphabetize the functions in your code with the first option?
Are you talking about putting types after the identifier? That is not a “Rust” thing. It is different than the Algol/C tradition but Rust did not invent it. If you ever try to write a compiler, you will find that it is a lot easier to parse this way. For one thing, type inference does not change the syntax. I think it makes deeply nested types easier to read. But that is just preference.
Take C# vs Kotlin
C#: String var1 = “” or var var1 = “”
Kotlin: val var1: String = “” or val var1 = “”
Most mainstream programming languages borrow syntax from the C lineage of languages. Rust is a member of the equally old and storied ML lineage which was intentionally garbed in borrowed C++ syntax to make it more approachable.
Those postfix type annotations are present in both OCaml (which Rust’s compiler was written in before it became self-hosting) and Wirth languages like Pascal and, in Rust’s case, there’s a good reason for them: Consistency.
You can use the same syntax with
fn
and withlet
without strewingauto
debris around all yourlet
statements to leave a hole for the types to go into.(And you can’t just omit the
let
because that was added as part of ensuring Rust doesn’t suffer from things like the Lexer Hack or the Most Vexing Parse.)As for using
.clone()
a lot, I need more details before I can say anything.IMO, Zig is a far more logical choice for the Kernel. There’d be far less drama given that C to Zig transition is natural, unlike the transition to Rust, which is really the new kitchen sink language.
Rust has a borrow checker, which prevents entire classes of memory related problems, including many kinds of security bugs. It’s the rare comp-sci innovation to make it’s way out of the research language sandbox, to a production programming language, and it’s kind of the point of using rust. Zig has some cool stuff too, but it doesn’t have that.
No, it prevents accessing invalid references, which is incredibly rare.
Carewolf,
Not just that, it can flag all manors of memory faults: leaks/double free/buffer overflows/invalid reference/improper synchronization/etc. These faults can slip by unnoticed in debugging and testing.
Isn’t “use after free” an example of “accessing invalid references”? Because those are hardly “incredibly rare”.
Use after free happens with pointers not references. While burrows replaces both C/C++ pointers and references, they are more similar to references, and you can’t free a reference.
Carewolf,
Ah, I suspect there’s been confusion over terminology. Many languages replace C pointers with references such that “new” and “delete” are reference operations even though these are pointer operations in C.
When you said “No, it prevents accessing invalid references, which is incredibly rare.” I can tell now you meant C references that don’t involve allocations or de-allocations, however that’s probably not what most people were thinking in the context of a discussion on rust’s memory protection which clearly is about allocation and deallocation faults (regardless of if we call them references or pointers).
With this clarification in mind, rustlang is capable of catching “new” and “delete” mistakes made by programmers even through complex scenarios that a C compiler can’t because it doesn’t have the borrow checker that CaptainN- mentioned.
Nah, zig isn’t stable and zig uses panic for handling error the exactly opposite of behavior someone would want in a kernel, but it can be good replacement for C in userspace programs like gnu utils
By the time that £inux meets its goals for Rust, Redox will have eaten their lunch anyways.
Squizzler,
I agree with you about linux having a hard time embracing rust and Redox making progress faster with rust, however linux is eating everyone else’s lunch in terms of market share. Alternatives like redox may have more difficulty reaching critical mass than achieving technical milestones.
The secret weapon for Linux is the GPL. We are really starting to see the strain of the more “free” license like MIT and BSD now, where many just kind of take, and never give on those projects.
I see Redox as successor to HURD as best hope to replace Linux (which is of course the kernel) with a more modern microkernel and associated services. Already we have a Rust GUI (Cosmic, etc) to sit on top of this.
I see them succeeding where HURD failed as largely being driven by the hype of a new language. Licensing being secondary. Fwiw I used to believe in BSD and similar licensing, but am socialist now, and prefer the GPL style. Genode for example, one of my favoured OS, uses AGPL, so I am pleased with that.
Wow, one day real so soon you might even have a real program in Rust.. Unfortunately you will never have real libraries as Rust is incompatible with proper shared libraries.
Firefox is a completely fake program, with fake libraries.
You could almost say the same thing about C++, given that:
1. It requires the same
extern "C"
dance that Rust does if you want to build a dynamic library with a C-compatible ABI.2. Any API surface using C++ templates (the counterpart to the generics Rust threads throughout the standard library) will be omitted from built C++ libraries because dynamic libraries with templates/generics without the sacrifice Swift make is just an unsolved problem.
Give https://blogs.gentoo.org/mgorny/2012/08/20/the-impact-of-cxx-templates-on-library-abi/ a read.
Rust is just better at refusing to let downstream consumers force de-facto stabilization of their unstable dynamic library ABI. (Yes, they do have the ability to build dynamic libraries… it’s just hard to find and may break ABI with even the slightest version bump.)
I mean this completely honestly to educate myself but what projects do you think are the best examples of where we are seeing this strain?
What I see is projects like Clang/LLVM overtaking GCC and doing it largely because of the significant corporate participation. The two most recent languages to be added to GCC are ALGOL and COBOL. LLVM is the basis for both Zig and Rust ( Apache and MIT licensed by the way ).
Many newer distros seem to be opting for MUSL over Glibc ( Alpine, Void, Adelie, Chimera ).
In your typical Linux distro, there is more software written with permissive licenses like MIT, BSD, and Apache2 than there is GPL. If you exclude Red Hat even moreso.
When I think of the most important GPL projects, many of them were started by corporations. That is not them being forced to contribute. It is them choosing copyleft for their contributions. Again though, a lot of the projects that I am thinking of are just Red Hat.
The dominant Open Source office suite, LibreOffice, is MPL ( more like MIT / BSD than the GPL ).
The success of gaming on Linux is largely commercially driven including of course CodeWeavers and Valve. Their preferred license seems to be BSD including both GameScope and WINE itself.
The entire Linux graphics stack ( Mesa, Wayland, X11 ) is MIT licensed and most of that code is corporate sponsored. Many of the designs are corporate contributions, including Vulkan. The biggest headache in this area has been NVIDIA. The GPL seems to have prevented them from contributing ore than it has encouraged them. Their “Open Source” driver has resulted in more code in their completely closed sourced components.
And I do not find the Linux kernel itself to be the best example to demonstrate how the GPL makes projects successful.
The comment we are applying to is about Redox replacing Linux ( MIT replacing GPL ). Not that I think Redox displacing Linux is likely.
Microsoft Windows and Microsoft Office became so popular partially due to a lack of enforcement of the license. Home users and small businesses largely ignored the license. Linux feels the same. I have worked in a few industries now where Linux absolutely dominates. Take video surveillance. Every device is Linux based. Almost all of them rely on proprietary applications built of top and proprietary SDKs to access specialized proprietary hardware. Ask me how may source code repositories I saw from any of these suppliers. If the GPL were strictly enforced, many of these suppliers would not use it.
More importantly though, Linux does not really act like other GPL software. Linux allows you to keep your bits proprietary. It has a special exception to let you link in binary bits as modules. Even if Linus held completely copyright authority over the entire kernel, we know he would not switch to GPL3 because he is totally ok with the “abuses” that both GPL 2 and the Linux license allows. And, in my view, that is precisely why Linux is so successful.
But, apologies, I was trying to ask a genuine question and it probably comes across like I am trying to fight about the GPL. Not a great way to get an answer.. If you think that Linux is successful because of the GPL, maybe you are right. I am totally fine with the GPL and have released GPL software myself.
What non-GPL projects have struggled because of their license in recent years and either been replaced by GPL software or been forced to switch their license to copyleft?
To me, it feels like things are going the other direction. Maybe I am missing something. Maybe using Chimera Linux lately has blinded me to the broader market.
Wine is LGPLed. It’s why, back in the day, Codeweavers Crossover spent a period of time as a fork of the last permissively-licensed Wine version before they managed to migrate their design over.
(These days, Codeweavers basically acts as the Freemium arm of Wine, employing the main Wine developers, upstreaming their patches as they grow ready, and with a launcher and lists of Windows applications they QA test and guarantee support for being their value-adds… basically a perfect success for what the LGPL is designed to do.)
Which is essentially LGPL in spirit if not in letter.
Time for companies that advocated for Rust to start producing upstream GNU/Linux Rust drivers.
Geck,
That’s very easily said, but it doesn’t mean rust contributions will automatically be welcome. There are C developers who consider rust a second class citizen and don’t actually want linux to accommodate rust.
“Filesystem in Rust – Kent Overstreet”
https://www.youtube.com/watch?v=WiPp9YEBV0Q&t=1529s
https://arstechnica.com/gadgets/2024/09/rust-in-linux-lead-retires-rather-than-deal-with-more-nontechnical-nonsense/
Regardless of which side one agrees with, whoever contributes rust may have to face unrelenting challenges from incumbent C developers. I happen to agree with Filho in the video, what he’s asking for is not unreasonable, but fighting with other developers isn’t what he signed up for.
I cannot comment on game / desktop developers, but I’ve been a bit surprised just how quickly Rust is being adopted or at least seriously investigated by the IIoT / IoT industry, I suppose it makes sense given you can still make the calls to established libraries and most IIoT / IoT Devs as using VSCode.