3 ms·

https://news.ycombinator.com/item?id=41386939 https://news.ycombinator.com/item?id=41386939 A comment there has a link to a video of what seems to be the final

https://news.ycombinator.com/item?id=41386939 https://news.ycombinator.com/item?id=41386939 A comment there has a link to a video of what seems to be the final straw.

Zambyte 2y ago
Also linked in the email in the GP. > Lastly, I'll leave a small, 3min 30s, sample for context here: https://youtu.be/WiPp9YEBV0Q?t=1529 https://youtu.be/WiPp9YEBV0Q?t=1529 -- and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code.
- theta_d 2y ago
  That was painful to watch.
- techwizrd 2y ago
  A redditor pointed out [0] that this is exactly what they would do to sink Rust adoption. Even if you agree with the substance of the argument, the delivery is rude and unhelpful. I hope this resignation is a wake-up call, and much of the onus is on C devs to be more collaborative. 0: https://www.reddit.com/r/linux/comments/1f3q0l8/one_of_the_rust_linux_kernel_maintainers_steps/lkgvejt/ https://www.reddit.com/r/linux/comments/1f3q0l8/one_of_the_r...
  - zozbot234 2y ago
    Why do C devs even have to be 'collaborative' about Rust modules? The latter would typically ingest C APIs, most likely via bindgen, making C code the "source of truth" about what the API is - because Rust modules are self-contained and C is the only stable ABI that Rust supports. All the type-checking smarts that the video talks about are purely on the Rust side. If a new 'raw' low-level C API is needed to build better smarts on the Rust side (which seems to be what's involved in some of the fs proposals) that can just be a self-contained proposal, with very lightweight changes on the C side of the code. This whole thing looks like a tempest in a teapot to me - and to be clear, this absolutely includes the Linux dev's complaints, which are extremely poor form.
    - progbits 2y ago
      Because they shouldn't be "C devs" but "kernel devs" with a common goal?
    - __s 2y ago
      Because internally the kernel maintains API compatibility, so if some internal C API changes the change needs to update rest of C code consuming it If kernel includes Rust, then that C code change could also require applying fixes to Rust code that breaks from that change
      - zozbot234 2y ago
        That burden would fall on Rust maintainers. If the Rust code goes unmaintained and nobody is around to pick it up, it just gets dropped from Linux releases that rely on the up-to-date C API.
        techwizrd 2y ago
        The Rust maintainers said they would maintain the Rust bindings. But wouldn't it be nice to have a heads up that the bindings might break? Or whether assumptions have changed? Or even what the assumptions are? It's a little tough to build a safe abstraction layer on top of C or encourage maintainers to stick around with a hostile "that's a _you_ problem" mentality or inaccurate rhetoric that Rust are trying to force their religion onto the C devs.
runjake 2y ago
For those who don’t or can’t watch the video, or want to know who is saying what, here’s an LWN article describing what happens in that section of video. https://lwn.net/Articles/978738/ https://lwn.net/Articles/978738/ While I disagree with his opinions here, Ted T'so is a long-time Linux kernel dev. He's been around since close to the beginning. https://en.wikipedia.org/wiki/Theodore_Ts%27o https://en.wikipedia.org/wiki/Theodore_Ts%27o
- kranuckle 2y ago
  [dead]

https://news.ycombinator.com/item?id=41386939 https://news.ycombinator.com/item?id=41386939 A comment there has a link to a video of what seems to be the final straw.

Zambyte 2y ago

Also linked in the email in the GP. > Lastly, I'll leave a small, 3min 30s, sample for context here: https://youtu.be/WiPp9YEBV0Q?t=1529 https://youtu.be/WiPp9YEBV0Q?t=1529 -- and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code.

theta_d 2y ago
That was painful to watch.
techwizrd 2y ago
A redditor pointed out [0] that this is exactly what they would do to sink Rust adoption. Even if you agree with the substance of the argument, the delivery is rude and unhelpful. I hope this resignation is a wake-up call, and much of the onus is on C devs to be more collaborative. 0: https://www.reddit.com/r/linux/comments/1f3q0l8/one_of_the_rust_linux_kernel_maintainers_steps/lkgvejt/ https://www.reddit.com/r/linux/comments/1f3q0l8/one_of_the_r...
- zozbot234 2y ago
  Why do C devs even have to be 'collaborative' about Rust modules? The latter would typically ingest C APIs, most likely via bindgen, making C code the "source of truth" about what the API is - because Rust modules are self-contained and C is the only stable ABI that Rust supports. All the type-checking smarts that the video talks about are purely on the Rust side. If a new 'raw' low-level C API is needed to build better smarts on the Rust side (which seems to be what's involved in some of the fs proposals) that can just be a self-contained proposal, with very lightweight changes on the C side of the code. This whole thing looks like a tempest in a teapot to me - and to be clear, this absolutely includes the Linux dev's complaints, which are extremely poor form.
  - progbits 2y ago
    Because they shouldn't be "C devs" but "kernel devs" with a common goal?
  - __s 2y ago
    Because internally the kernel maintains API compatibility, so if some internal C API changes the change needs to update rest of C code consuming it If kernel includes Rust, then that C code change could also require applying fixes to Rust code that breaks from that change
    - zozbot234 2y ago
      That burden would fall on Rust maintainers. If the Rust code goes unmaintained and nobody is around to pick it up, it just gets dropped from Linux releases that rely on the up-to-date C API.
      - techwizrd 2y ago
        The Rust maintainers said they would maintain the Rust bindings. But wouldn't it be nice to have a heads up that the bindings might break? Or whether assumptions have changed? Or even what the assumptions are? It's a little tough to build a safe abstraction layer on top of C or encourage maintainers to stick around with a hostile "that's a _you_ problem" mentality or inaccurate rhetoric that Rust are trying to force their religion onto the C devs.

runjake 2y ago

For those who don’t or can’t watch the video, or want to know who is saying what, here’s an LWN article describing what happens in that section of video. https://lwn.net/Articles/978738/ https://lwn.net/Articles/978738/ While I disagree with his opinions here, Ted T'so is a long-time Linux kernel dev. He's been around since close to the beginning. https://en.wikipedia.org/wiki/Theodore_Ts%27o https://en.wikipedia.org/wiki/Theodore_Ts%27o

kranuckle 2y ago
[dead]