3 ms·

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

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.

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.