9 ms·

Rust in Linux lead retires rather than deal with more "nontechnical nonsense"

69 points by stalfosknight 2y ago

alephnerd 2y ago
I wish OSS projects had way less drama. Rust for Linux had great potential, and would have been a cool alternative to the existing C driven model. At least eBPF has diverse corporate sponsorship, so drama is somewhat tempered. Would be great if more companies pitched in to help the FOSS ecosystem, otherwise the only option is an Open Core model.
- SoftTalker 2y ago
  All projects have drama. The bigger the project the more drama. Just how people are.
- MayeulC 2y ago
  It's just the current lead retiring, Rust for Linux is far from dead.
- progmetaldev 2y ago
  I agree on the desire for less drama, but being as OSS has lots of support from people that have made it their passion, I'd expect less drama would mean less caring about the project. Having companies support OSS project more could help, but would also need to be balanced by what is "best" for the project, which could just push drama more towards being monetarily driven. I just hope that this doesn't become an issue that causes a fracture big enough to split the community.
pitched 2y ago
As a casual Rust user, I feel it’s a bit ridiculous to think something could outdo Linux only by choice of programming language. Is that the “nontechnical nonsense” here?
- 3836293648 2y ago
  No, bullying is
  - hgaskj 2y ago
    The quote from T'so in the article is hardly bullying. I found it telling that this was presented as evidence of hostility. Predictably, the Rust people play the victims while they are the ones who are asking something from all other kernel developers.
    - PointyFluff 2y ago
      [dead]
    - bfrog 2y ago
      "Trying to get everyone to switch over to the religion..." Yeah I mean I don't see how you don't hear this person talking and not think they are disdainful and dismissive. In other news, Redox continues to improve and an amazing pace. May the best kernel win.
      - astrange 2y ago
        https://en.wikipedia.org/wiki/Redox_(operating_system) https://en.wikipedia.org/wiki/Redox_(operating_system) > Ralloc – memory allocator > RedoxFS (file system) – inspired by the ZFS file system It doesn't seem necessary to write either one of these if you just want a Rust kernel. For one thing, secure malloc replacements are not very useful because the main customer that needs them, web browsers, will ignore yours because it's "too slow" and continue using their own. (Also, unless you're testing on an MTE/CHERI system your assumptions about what makes one secure are probably incorrect.)
        klingoff 2y ago
        Google and a bunch of bounties worry about the security of malloc for their browser, some intern worries about the security of the enterprise server.
AdeptusAquinas 2y ago
I support the c coders. Rewriting linux in rust is an existential threat to the infosec industry where I work
- minkles 2y ago
  You can still write security software that fucks up the kernel in Rust! Edit: just in case anyone took this too seriously, it was facetious.
  - doubled112 2y ago
    Would a new competitor "cloudstrike-rs" be too blatant a trademark infringement?
    - minkles 2y ago
      Close. What about Ruststrike? Edit: I don't even know Rust but I wrote a prototype: fn main() { const LOL: *mut u64 = 1 as *mut u64; unsafe { std::ptr::write(LOL, 0); } } Edit 2: fuck that's ugly.
- antisthenes 2y ago
  Well, the infosec industry itself is an existential threat to sane, responsive software for power users without the cult of safetyism, so it is potentially still a net win. The safest software is the one that does nothing.
  - AdeptusAquinas 2y ago
    That's the spirit! People with attitudes like that are why my salary keeps going up.
    - actionfromafar 2y ago
      How can I get on your (salary) bandwagon?
pdimitar 2y ago
Very sad event. People gatekeeping so hard is just flabbergasting to see.
Cieric 2y ago
I personally have complaints about bringing rust into the Linux kernel (not a maintainer or contributor so my opinion matters very little), however making changes to the kernel to make it safer or more robust should always be welcome. I'm curious if this is a case of only getting a single side of the story or not though. I've heard a lot from the rust side, but nothing from the c side of the issue (obviously response is pending.) I'm going to wait on forming an opinion on the limited information currently available.
- hgaskj 2y ago
  [flagged]
- logicchains 2y ago
  I'd guess compile time would be a complaint, since Rust generally takes a lot longer to compile than equivalent C. Safety is one thing, but it isn't the be-all and end-all of kernel development; feature development is also important, and reducing productivity impacts that.
  - Aeolos 2y ago
    Rust is a significantly more productive language than C. It's not even a comparison. Proof: Asahi Lina wrote an entire driver for a modern GPU, with zero reported runtime crashes, and explicitly stated this would have been impossible in C.
- DSMan195276 2y ago
  I've very casually followed this process (lwn articles, read a few emails) and honestly I feel like this was predictable, the problem is the maintenance cost this places on the maintainers. The kernel is developed as one whole thing, the internal C APIs get changed and those changes are applied to all the code contained in the codebase. If there's Rust code calling those APIs then it needs to be fixed as well and they don't know how to do that. Obviously you can argue over whether the need to maintain the Rust code would end up improving the C code as a result, but ultimately Linus isn't pushing hard for this to happen. Those who want Rust in the kernel need to convince those who will end up maintaining the Rust code why it's worth having, and I don't think that step has been successful.
minkles 2y ago
Gonna write my own kernel, with Rust, blackjack and hookers! That's how this ends. And I'm fine with that. May the best solution win.
- hindsightbias 2y ago
  Prediction: And in 20 years, Rustnix coders will be gatekeeping the next shiny language.
  - minkles 2y ago
    Nah they will be scratching their butts like GNU Herd programmers are. Momentum is a bitch. It's why Windows still exists.
    - generalizations 2y ago
      From what I've understood about Rust, they'll be bogged down in a verbose language, and may never reach feature parity. Their only hope of getting Rust into a mainstream kernel is probably to take over an existing project.
      - minkles 2y ago
        That sounds feasible. I just wrote my first Rust program (search for Ruststrike in this thread) and wow it's stupid verbose and not particularly safe if put in my hands. I can see while there is determinism and fewer footguns, it painful on a C++ level to write. I think just having less in the kernel and moving bits out (like Mach) into isolated domains is probably better than reinventing the universe for some purity argument.
        hindsightbias 2y ago
        Maybe spec Rust++ with Tevanian? He must be bored by now.
        iknowstuff 2y ago
vlovich123 2y ago
Things like this remind me of Planck's principle: > A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die and a new generation grows up that is familiar with it It's interesting to hear the complaint is "you can't make me learn another language" from someone like Ted Tso. Learning your 2nd language is very hard but at some point it becomes routine, especially since a good chunk of these languages are all Algol-based in some sense. And the main "new" thing is different concepts like functional ways to write programs and various other ergonomic improvements. But really those things just make your code clearer. https://en.wikipedia.org/wiki/Planck%27s_principle https://en.wikipedia.org/wiki/Planck%27s_principle
- bluGill 2y ago
  Learning a 2nd programming language isn't a big deal. Learning 2000 is a big deal. All projects should thus carefully limit what languages they allow so that people working in them don't have to learn too many. However you should also be learning new languages once in a while just for personal growth reasons. If you write code in a memory unsafe language reading about Rust's borrow checker should be very interesting to you. You might conclude it isn't compelling on its own, but you should be very interested and at least thinking about how you can solve the problem in your current code (which might be adopting Rust, might be some other language, or might be change to your current language). If you don't admit that Rust solves a difficult problem I have no discussion for you - but you can say that the downsides to rust are not worth it.
uv-depression 2y ago
It really does seem like there's some old-guard who are utterly determined to now allow this to happen. That's not to say that Rust is inevitable in the kernel, but they're refusing to even allow the attempt. The amount of bad-faith argumentation happening is really discouraging about the state of Linux development. In addition, the changes needed on the C side for RiL are needed anyways! Lifetimes aren't just a Rust thing, it just makes them forefront. You still need to keep track of them in C, and so they need to be documented since the language sure isn't going to help you. Refusing to document them isn't just harming Rust in Linux, it's harming the long-term viability of Linux in general. When the current maintainers quit, who's going to be able to untangle all that? Bug fixes still need to happen if they're only discovered because someone tried to formalize your interface!
- fsckboy 2y ago
  >It really does seem like there's some old-guard who are utterly determined to now allow this to happen. unices and then into the linux project have been a massively successful series of massive C library/API/threading/timing/bittwiddling coordination efforts. some people now want to turn that Ship of Theseus into catamaran, while it's sailing? Rust people could probably more easily just use the Linux sources and rewrite it into a new better system, clean effort. Coordinating people is time consuming and difficult, and this "project" clearly makes that issue a lot worse in the interim phases. Seems downright Bayesian, if you know what I mean.
  - bitexploder 2y ago
    Linux is like 27 million lines of code. The core is several million. I think efforts like gVisor and other sandboxing technologies are the future. gVisor and friends like it can minimize the attack surface of unsafe code down to some minimum. Rust in Linux as an experiment should go on. Core functionality can likely be re-implemented in Rust and continue to get some meaningful % of the critical path of code safer, but there will always be some level of "unsafe" code in an operating system kernel.
  - bluGill 2y ago
    Anybody can write a good kernel for one single computer (not just CPU) in a couple years. What makes linux useful is the vast amount of different hardware combinations it supports, often with "black magic" because some hardware doesn't work unless you do something weird (commonly you have to wait some amount of time after the power comes on before using it). One computer is easy, adding support for a second that is even slightly different is more work. Linux works correctly on millions of combinations by now (most of those combinations have not been tested but they would work)
elpocko 2y ago
https://news.ycombinator.com/item?id=41386939 https://news.ycombinator.com/item?id=41386939 https://news.ycombinator.com/item?id=41387924 https://news.ycombinator.com/item?id=41387924 https://news.ycombinator.com/item?id=41423146 https://news.ycombinator.com/item?id=41423146 https://news.ycombinator.com/item?id=41424608 https://news.ycombinator.com/item?id=41424608 https://news.ycombinator.com/item?id=41431856 https://news.ycombinator.com/item?id=41431856 https://news.ycombinator.com/item?id=41438402 https://news.ycombinator.com/item?id=41438402 https://news.ycombinator.com/item?id=41443306 https://news.ycombinator.com/item?id=41443306
oldpersonintx 2y ago
[dead]
the_real_cher 2y ago
I'm hearing word of Zig being an even better language than Rust.
- minkles 2y ago
  I was considering writing a microkernel OS in Zig that transpiles to Rust and targets WebAssembly on a RISC-V CPU. That would be ultimate security. No one would be able to peel off all the layers!
  - the_real_cher 2y ago
    It's a shame that we don't have React components in the Linux kernel.
- saagarjha 2y ago
  Not for the reasons the kernel needs.
deleted 2y ago
[deleted]
deleted 2y ago
[deleted]
johnea 2y ago
[flagged]
jmull 2y ago
I think we need to consider the perspective of the linux maintainers. Learning and mastering a new language and applying it to an existing code base is quite a lot of work. That takes a lot of time away from other things they might be working on. I think these are mostly (overwhelmingly?) volunteers, so you can't just assign them work. You need to convince them to want to do the work. Doing this shouldn't be dismissed as nontechnical nonsense... it's a very significant hurdle, and one that's directly on the critical path. BTW, naming and shaming and internet pitchforks are guaranteed to make people not want to do the work, so unless you actually want to kill rust-in-linux, you might want to shut that down. (Also, I wonder if there isn't a better way to bring memory-safety to the linux kernel. One that is just as effective as rust but less disruptive. The hostile us-vs-them dynamic building up around RiL might torpedo the whole thing, so it might be worth looking for effective alternatives.)
- bryanlarsen 2y ago
  > Learning and mastering a new language and applying it to an existing code base is quite a lot of work. That takes a lot of time away from other things they might be working on. Nobody is asking them to do that. They are being asked to review C patches to enable Rust-in-Linux. > I think these are mostly (overwhelmingly?) volunteers, so you can't just assign them work The vast majority are professionals. A few work for the Linux Foundation, many work full time on Linux inside of big corps. For example, Ted T'so works for Google.
  - jorams 2y ago
    > Nobody is asking them to do that. They are being asked to review C patches to enable Rust-in-Linux. My understanding of their issue is that this can't really be true. Any C code that affects Rust bindings in any way (which will be more and more as long as the integration grows) will become impossible to change without either knowing Rust or hoping/waiting for someone else to pick up that part.
    - steveklabnik 2y ago
      They are repeating this as if it’s true when it’s been explained that it is not. The Rust for Linux people have committed to picking it up. They don’t even have to wait for them to do that work before merging, though they did ask if they could get a heads up email so the turnaround time would be faster.
sazz 2y ago
For me, this discussion won't lead anywhere because it covers the wrong topic. It's not about Rust or C - it's about transparency. The existing maintainers assume that it is not a priority for them whether they break something downstream or not. They therefore work in a space with interfaces that they can change as they see fit, without giving any guarantees as to their continued existence or wanting to subordinate themselves to a defined change process. Rust is just a symptom of growing pains. Growth would be achieved if they could agree on common rules which would foster independent development linked by the interface contracts. Instead, the issue is that established maintainers have grown fond of their zoo and are only pursuing their own priorities in a landlord-like manner. On the other hand, they see new technologies appearing and disappearing on the horizon and have consequently realized that a new technology or language cannot improve an existing system. And yet they are classically talking past each other.

69 points by stalfosknight 2y ago

I wish OSS projects had way less drama. Rust for Linux had great potential, and would have been a cool alternative to the existing C driven model. At least eBPF has diverse corporate sponsorship, so drama is somewhat tempered. Would be great if more companies pitched in to help the FOSS ecosystem, otherwise the only option is an Open Core model.

SoftTalker 2y ago
All projects have drama. The bigger the project the more drama. Just how people are.
MayeulC 2y ago
It's just the current lead retiring, Rust for Linux is far from dead.
progmetaldev 2y ago
I agree on the desire for less drama, but being as OSS has lots of support from people that have made it their passion, I'd expect less drama would mean less caring about the project. Having companies support OSS project more could help, but would also need to be balanced by what is "best" for the project, which could just push drama more towards being monetarily driven. I just hope that this doesn't become an issue that causes a fracture big enough to split the community.

pitched 2y ago

As a casual Rust user, I feel it’s a bit ridiculous to think something could outdo Linux only by choice of programming language. Is that the “nontechnical nonsense” here?

3836293648 2y ago
No, bullying is
- hgaskj 2y ago
  The quote from T'so in the article is hardly bullying. I found it telling that this was presented as evidence of hostility. Predictably, the Rust people play the victims while they are the ones who are asking something from all other kernel developers.
  - PointyFluff 2y ago
    [dead]
  - bfrog 2y ago
    "Trying to get everyone to switch over to the religion..." Yeah I mean I don't see how you don't hear this person talking and not think they are disdainful and dismissive. In other news, Redox continues to improve and an amazing pace. May the best kernel win.
    - astrange 2y ago
      https://en.wikipedia.org/wiki/Redox_(operating_system) https://en.wikipedia.org/wiki/Redox_(operating_system) > Ralloc – memory allocator > RedoxFS (file system) – inspired by the ZFS file system It doesn't seem necessary to write either one of these if you just want a Rust kernel. For one thing, secure malloc replacements are not very useful because the main customer that needs them, web browsers, will ignore yours because it's "too slow" and continue using their own. (Also, unless you're testing on an MTE/CHERI system your assumptions about what makes one secure are probably incorrect.)
      - klingoff 2y ago
        Google and a bunch of bounties worry about the security of malloc for their browser, some intern worries about the security of the enterprise server.

AdeptusAquinas 2y ago

I support the c coders. Rewriting linux in rust is an existential threat to the infosec industry where I work

minkles 2y ago
You can still write security software that fucks up the kernel in Rust! Edit: just in case anyone took this too seriously, it was facetious.
- doubled112 2y ago
  Would a new competitor "cloudstrike-rs" be too blatant a trademark infringement?
  - minkles 2y ago
    Close. What about Ruststrike? Edit: I don't even know Rust but I wrote a prototype: fn main() { const LOL: *mut u64 = 1 as *mut u64; unsafe { std::ptr::write(LOL, 0); } } Edit 2: fuck that's ugly.
antisthenes 2y ago
Well, the infosec industry itself is an existential threat to sane, responsive software for power users without the cult of safetyism, so it is potentially still a net win. The safest software is the one that does nothing.
- AdeptusAquinas 2y ago
  That's the spirit! People with attitudes like that are why my salary keeps going up.
  - actionfromafar 2y ago
    How can I get on your (salary) bandwagon?

pdimitar 2y ago

Very sad event. People gatekeeping so hard is just flabbergasting to see.

Cieric 2y ago

I personally have complaints about bringing rust into the Linux kernel (not a maintainer or contributor so my opinion matters very little), however making changes to the kernel to make it safer or more robust should always be welcome. I'm curious if this is a case of only getting a single side of the story or not though. I've heard a lot from the rust side, but nothing from the c side of the issue (obviously response is pending.) I'm going to wait on forming an opinion on the limited information currently available.

hgaskj 2y ago
[flagged]
logicchains 2y ago
I'd guess compile time would be a complaint, since Rust generally takes a lot longer to compile than equivalent C. Safety is one thing, but it isn't the be-all and end-all of kernel development; feature development is also important, and reducing productivity impacts that.
- Aeolos 2y ago
  Rust is a significantly more productive language than C. It's not even a comparison. Proof: Asahi Lina wrote an entire driver for a modern GPU, with zero reported runtime crashes, and explicitly stated this would have been impossible in C.
DSMan195276 2y ago
I've very casually followed this process (lwn articles, read a few emails) and honestly I feel like this was predictable, the problem is the maintenance cost this places on the maintainers. The kernel is developed as one whole thing, the internal C APIs get changed and those changes are applied to all the code contained in the codebase. If there's Rust code calling those APIs then it needs to be fixed as well and they don't know how to do that. Obviously you can argue over whether the need to maintain the Rust code would end up improving the C code as a result, but ultimately Linus isn't pushing hard for this to happen. Those who want Rust in the kernel need to convince those who will end up maintaining the Rust code why it's worth having, and I don't think that step has been successful.

minkles 2y ago

Gonna write my own kernel, with Rust, blackjack and hookers! That's how this ends. And I'm fine with that. May the best solution win.

hindsightbias 2y ago
Prediction: And in 20 years, Rustnix coders will be gatekeeping the next shiny language.
- minkles 2y ago
  Nah they will be scratching their butts like GNU Herd programmers are. Momentum is a bitch. It's why Windows still exists.
  - generalizations 2y ago
    From what I've understood about Rust, they'll be bogged down in a verbose language, and may never reach feature parity. Their only hope of getting Rust into a mainstream kernel is probably to take over an existing project.
    - minkles 2y ago
      That sounds feasible. I just wrote my first Rust program (search for Ruststrike in this thread) and wow it's stupid verbose and not particularly safe if put in my hands. I can see while there is determinism and fewer footguns, it painful on a C++ level to write. I think just having less in the kernel and moving bits out (like Mach) into isolated domains is probably better than reinventing the universe for some purity argument.
      - hindsightbias 2y ago
        Maybe spec Rust++ with Tevanian? He must be bored by now.
      - iknowstuff 2y ago

vlovich123 2y ago

Things like this remind me of Planck's principle: > A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die and a new generation grows up that is familiar with it It's interesting to hear the complaint is "you can't make me learn another language" from someone like Ted Tso. Learning your 2nd language is very hard but at some point it becomes routine, especially since a good chunk of these languages are all Algol-based in some sense. And the main "new" thing is different concepts like functional ways to write programs and various other ergonomic improvements. But really those things just make your code clearer. https://en.wikipedia.org/wiki/Planck%27s_principle https://en.wikipedia.org/wiki/Planck%27s_principle

bluGill 2y ago
Learning a 2nd programming language isn't a big deal. Learning 2000 is a big deal. All projects should thus carefully limit what languages they allow so that people working in them don't have to learn too many. However you should also be learning new languages once in a while just for personal growth reasons. If you write code in a memory unsafe language reading about Rust's borrow checker should be very interesting to you. You might conclude it isn't compelling on its own, but you should be very interested and at least thinking about how you can solve the problem in your current code (which might be adopting Rust, might be some other language, or might be change to your current language). If you don't admit that Rust solves a difficult problem I have no discussion for you - but you can say that the downsides to rust are not worth it.

uv-depression 2y ago

It really does seem like there's some old-guard who are utterly determined to now allow this to happen. That's not to say that Rust is inevitable in the kernel, but they're refusing to even allow the attempt. The amount of bad-faith argumentation happening is really discouraging about the state of Linux development. In addition, the changes needed on the C side for RiL are needed anyways! Lifetimes aren't just a Rust thing, it just makes them forefront. You still need to keep track of them in C, and so they need to be documented since the language sure isn't going to help you. Refusing to document them isn't just harming Rust in Linux, it's harming the long-term viability of Linux in general. When the current maintainers quit, who's going to be able to untangle all that? Bug fixes still need to happen if they're only discovered because someone tried to formalize your interface!

fsckboy 2y ago
>It really does seem like there's some old-guard who are utterly determined to now allow this to happen. unices and then into the linux project have been a massively successful series of massive C library/API/threading/timing/bittwiddling coordination efforts. some people now want to turn that Ship of Theseus into catamaran, while it's sailing? Rust people could probably more easily just use the Linux sources and rewrite it into a new better system, clean effort. Coordinating people is time consuming and difficult, and this "project" clearly makes that issue a lot worse in the interim phases. Seems downright Bayesian, if you know what I mean.
- bitexploder 2y ago
  Linux is like 27 million lines of code. The core is several million. I think efforts like gVisor and other sandboxing technologies are the future. gVisor and friends like it can minimize the attack surface of unsafe code down to some minimum. Rust in Linux as an experiment should go on. Core functionality can likely be re-implemented in Rust and continue to get some meaningful % of the critical path of code safer, but there will always be some level of "unsafe" code in an operating system kernel.
- bluGill 2y ago
  Anybody can write a good kernel for one single computer (not just CPU) in a couple years. What makes linux useful is the vast amount of different hardware combinations it supports, often with "black magic" because some hardware doesn't work unless you do something weird (commonly you have to wait some amount of time after the power comes on before using it). One computer is easy, adding support for a second that is even slightly different is more work. Linux works correctly on millions of combinations by now (most of those combinations have not been tested but they would work)

elpocko 2y ago

https://news.ycombinator.com/item?id=41386939 https://news.ycombinator.com/item?id=41386939 https://news.ycombinator.com/item?id=41387924 https://news.ycombinator.com/item?id=41387924 https://news.ycombinator.com/item?id=41423146 https://news.ycombinator.com/item?id=41423146 https://news.ycombinator.com/item?id=41424608 https://news.ycombinator.com/item?id=41424608 https://news.ycombinator.com/item?id=41431856 https://news.ycombinator.com/item?id=41431856 https://news.ycombinator.com/item?id=41438402 https://news.ycombinator.com/item?id=41438402 https://news.ycombinator.com/item?id=41443306 https://news.ycombinator.com/item?id=41443306

oldpersonintx 2y ago

[dead]

the_real_cher 2y ago

I'm hearing word of Zig being an even better language than Rust.

minkles 2y ago
I was considering writing a microkernel OS in Zig that transpiles to Rust and targets WebAssembly on a RISC-V CPU. That would be ultimate security. No one would be able to peel off all the layers!
- the_real_cher 2y ago
  It's a shame that we don't have React components in the Linux kernel.
saagarjha 2y ago
Not for the reasons the kernel needs.

deleted 2y ago

[deleted]

deleted 2y ago

[deleted]

johnea 2y ago

[flagged]

jmull 2y ago

I think we need to consider the perspective of the linux maintainers. Learning and mastering a new language and applying it to an existing code base is quite a lot of work. That takes a lot of time away from other things they might be working on. I think these are mostly (overwhelmingly?) volunteers, so you can't just assign them work. You need to convince them to want to do the work. Doing this shouldn't be dismissed as nontechnical nonsense... it's a very significant hurdle, and one that's directly on the critical path. BTW, naming and shaming and internet pitchforks are guaranteed to make people not want to do the work, so unless you actually want to kill rust-in-linux, you might want to shut that down. (Also, I wonder if there isn't a better way to bring memory-safety to the linux kernel. One that is just as effective as rust but less disruptive. The hostile us-vs-them dynamic building up around RiL might torpedo the whole thing, so it might be worth looking for effective alternatives.)

bryanlarsen 2y ago
> Learning and mastering a new language and applying it to an existing code base is quite a lot of work. That takes a lot of time away from other things they might be working on. Nobody is asking them to do that. They are being asked to review C patches to enable Rust-in-Linux. > I think these are mostly (overwhelmingly?) volunteers, so you can't just assign them work The vast majority are professionals. A few work for the Linux Foundation, many work full time on Linux inside of big corps. For example, Ted T'so works for Google.
- jorams 2y ago
  > Nobody is asking them to do that. They are being asked to review C patches to enable Rust-in-Linux. My understanding of their issue is that this can't really be true. Any C code that affects Rust bindings in any way (which will be more and more as long as the integration grows) will become impossible to change without either knowing Rust or hoping/waiting for someone else to pick up that part.
  - steveklabnik 2y ago
    They are repeating this as if it’s true when it’s been explained that it is not. The Rust for Linux people have committed to picking it up. They don’t even have to wait for them to do that work before merging, though they did ask if they could get a heads up email so the turnaround time would be faster.

sazz 2y ago

For me, this discussion won't lead anywhere because it covers the wrong topic. It's not about Rust or C - it's about transparency. The existing maintainers assume that it is not a priority for them whether they break something downstream or not. They therefore work in a space with interfaces that they can change as they see fit, without giving any guarantees as to their continued existence or wanting to subordinate themselves to a defined change process. Rust is just a symptom of growing pains. Growth would be achieved if they could agree on common rules which would foster independent development linked by the interface contracts. Instead, the issue is that established maintainers have grown fond of their zoo and are only pursuing their own priorities in a landlord-like manner. On the other hand, they see new technologies appearing and disappearing on the horizon and have consequently realized that a new technology or language cannot improve an existing system. And yet they are classically talking past each other.