For those who failed to read TA, Linus appears to finally have read the PR and decided that what was indeed submitted was client code. No, he’s not forcing subsystem maintainers to adopt Rust; he’s saying they can’t object to clients using Rust.
The fact is, the pull request you objected to DID NOT TOUCH THE DMA LAYER AT ALL.
“The document claims no subsystem is forced to take Rust”
that is very much true.
but as a result they also won’t have any say on what goes on on the Rust side.
there’s that “wall of protection” around C developers that don’t want to deal with Rust issues in the promise that they don’t have to deal with Rust.
If you don’t want to deal with the Rust code, you get no say on the Rust code.
I didn’t read the patches, but what I see is that Linus believes that the original objection to the PR was wrong. He’s asserting that subsystem maintainers who choose to not interact with client code get no say in whether the code is merged or not.
What he’s not saying is that subsystem maintainers have to start including Rust in the subsystems; this isn’t Linus forcing people to adopt Rust.
What I find most interesting about this is the whole premise of allowing Rust into the main tree. I’m sure there was a process, but does that mean now the wedge is in the door and people can start arguing about including Haskell? It would seem to me that once you make an exception, your argument for rejecting other languages becomes weaker. Why not Ada? It’s at least as memory safe - if not more - than Rust. Haskell programs can be provably correct, and there are tools for these proofs. This is an even more powerful argument for Haskell over Rust - it’s as memory safe, but also provide Curry-Howard correspondence, which Rust doesn’t. Is it a popularity contest? What about Zig, which is in the Rust ballpark for safety, but vastly superior compile times (and, arguably a more simple mental model)? Odin? These are all type-safe, compiled languages without a runtime (hence, no Go).
Most of the languages you’ve mentioned aren’t systems languages, so don’t make being a good language to write an OS in a high priority. More languages might be accepted in the future, but if they are, it’ll be ones that are a natural fit for the problems they’re solving.
I don’t know about Ada, except in jokes about how hard it is to write code that satisfies the compiler, which gives it something in common with Rust. Haskell is a horrible systems language. OCaml might be better. But I don’t think it’s justified to claim Zig isn’t suitably for systems programming, or for writing OSes. Maybe even Odin, but I’m only peripherally aware of it, and don’t know its strengths. Both are young and immature compared to Rust.
What will be hilarious is when, a little down the road, something like Zig will be mature; I’d bet money the loudest gate-keepers objecting to letting it in will be Rustaceans saying some shit like, “Rust already satisfies the safety needs of the kernel; there’s no need to add another language.”
I’m very firmly in the Rust for Linux camp because I am in the “make Linux better” camp, and I don’t see why eventually getting Zig in the kernel would be a problem. If Zig solves problems that C and Rust don’t, by all means, it should be brought in.
However, one of the primary reasons Rust was chosen is that it is memory-safe by default. Zig, on the other hand, has opt-in safety. So unsafe Zig should probably only go in very specific places where C and Rust can’t do the job. And ideally, there would be some rules that require the usage of safe Zig everywhere else.
Ignoring Zig, the language, Zig’s compiler toolchain is hands-down, the best I’ve ever seen, and I think introducing Zig to the kernel by making “Zig-built Linux” a thing, would be a really natural way to get that process going.
I don’t believe, Zig provides much in terms of safety? To my knowledge, it uses manual memory management à la C, just being less horrid in some aspects, like using an option type instead of null pointers.
I really don’t see why they should feel obliged to include another language, just because they included Rust. There is no fairness guarantee or whatever. If anything, Rust now fills the memory safety and modern language gap, so there is much less of a need to include another language.
This is cult-like shut-out tactics plain and simple. Get your foot in the door, keep everyone else out. Rust is superior! All code must be Rust! All other languages get the Axe!
This behavior is heavily agenda-driven and needs to stop.
You might want to ease up on the conspiracy theories. I’m not part of some irustinati that wants to force everyone to use Rust and nothing else. I was merely describing what I believe to be reality. In fact, I expect the strongest opposition to a third language will come again from those who’ve been coding nothing but C for the past decades.
For those who failed to read TA, Linus appears to finally have read the PR and decided that what was indeed submitted was client code. No, he’s not forcing subsystem maintainers to adopt Rust; he’s saying they can’t object to clients using Rust.
I didn’t read the patches, but what I see is that Linus believes that the original objection to the PR was wrong. He’s asserting that subsystem maintainers who choose to not interact with client code get no say in whether the code is merged or not.
What he’s not saying is that subsystem maintainers have to start including Rust in the subsystems; this isn’t Linus forcing people to adopt Rust.
What I find most interesting about this is the whole premise of allowing Rust into the main tree. I’m sure there was a process, but does that mean now the wedge is in the door and people can start arguing about including Haskell? It would seem to me that once you make an exception, your argument for rejecting other languages becomes weaker. Why not Ada? It’s at least as memory safe - if not more - than Rust. Haskell programs can be provably correct, and there are tools for these proofs. This is an even more powerful argument for Haskell over Rust - it’s as memory safe, but also provide Curry-Howard correspondence, which Rust doesn’t. Is it a popularity contest? What about Zig, which is in the Rust ballpark for safety, but vastly superior compile times (and, arguably a more simple mental model)? Odin? These are all type-safe, compiled languages without a runtime (hence, no Go).
Most of the languages you’ve mentioned aren’t systems languages, so don’t make being a good language to write an OS in a high priority. More languages might be accepted in the future, but if they are, it’ll be ones that are a natural fit for the problems they’re solving.
I don’t know about Ada, except in jokes about how hard it is to write code that satisfies the compiler, which gives it something in common with Rust. Haskell is a horrible systems language. OCaml might be better. But I don’t think it’s justified to claim Zig isn’t suitably for systems programming, or for writing OSes. Maybe even Odin, but I’m only peripherally aware of it, and don’t know its strengths. Both are young and immature compared to Rust.
What will be hilarious is when, a little down the road, something like Zig will be mature; I’d bet money the loudest gate-keepers objecting to letting it in will be Rustaceans saying some shit like, “Rust already satisfies the safety needs of the kernel; there’s no need to add another language.”
I’m very firmly in the Rust for Linux camp because I am in the “make Linux better” camp, and I don’t see why eventually getting Zig in the kernel would be a problem. If Zig solves problems that C and Rust don’t, by all means, it should be brought in.
However, one of the primary reasons Rust was chosen is that it is memory-safe by default. Zig, on the other hand, has opt-in safety. So unsafe Zig should probably only go in very specific places where C and Rust can’t do the job. And ideally, there would be some rules that require the usage of safe Zig everywhere else.
Ignoring Zig, the language, Zig’s compiler toolchain is hands-down, the best I’ve ever seen, and I think introducing Zig to the kernel by making “Zig-built Linux” a thing, would be a really natural way to get that process going.
I don’t believe, Zig provides much in terms of safety? To my knowledge, it uses manual memory management à la C, just being less horrid in some aspects, like using an option type instead of null pointers.
I really don’t see why they should feel obliged to include another language, just because they included Rust. There is no fairness guarantee or whatever. If anything, Rust now fills the memory safety and modern language gap, so there is much less of a need to include another language.
This is cult-like shut-out tactics plain and simple. Get your foot in the door, keep everyone else out. Rust is superior! All code must be Rust! All other languages get the Axe!
This behavior is heavily agenda-driven and needs to stop.
You might want to ease up on the conspiracy theories. I’m not part of some irustinati that wants to force everyone to use Rust and nothing else. I was merely describing what I believe to be reality. In fact, I expect the strongest opposition to a third language will come again from those who’ve been coding nothing but C for the past decades.
Feeding the troll 🤷♂️ “agenda driven” what does that even mean 😆
No one said other languages aren’t allowed. Submit a patch and prepare yourself for years of painstaking effort.