Defining the Rust 2024 edition

Posted Jan 31, 2024 14:25 UTC (Wed) by mb (subscriber, #50428)
In reply to: Defining the Rust 2024 edition by bluca
Parent article: Defining the Rust 2024 edition

Why would the Rust stdlib export a C interface? That doesn't make any sense at all.

Defining the Rust 2024 edition

Posted Jan 31, 2024 15:46 UTC (Wed) by bluca (subscriber, #118303) [Link] (5 responses)

Hence, it is not true that you can already have a stable ABI in rust

Defining the Rust 2024 edition

Posted Jan 31, 2024 16:01 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (4 responses)

I didn't say that. I said that if you want to expose a stable ABI from a Rust or C++ library, the only sensible way is to do it as a C wrapper, just like librsvg or libclang do. And possibly add language-independent introspection based on e.g. COM or GObject.

Defining the Rust 2024 edition

Posted Jan 31, 2024 19:01 UTC (Wed) by bluca (subscriber, #118303) [Link] (3 responses)

Exactly, and that's the problem

Defining the Rust 2024 edition

Posted Feb 1, 2024 8:38 UTC (Thu) by pbonzini (subscriber, #60935) [Link] (2 responses)

But it's not a Rust-specific problem, C++ has the same issue. And that's making me think there isn't really a solution.

Defining the Rust 2024 edition

Posted Feb 1, 2024 10:07 UTC (Thu) by farnz (subscriber, #17727) [Link]

Not just C++; even C has this problem to a small degree. The ELF ABIs don't cover the full C language; if I change a significant preprocessor definition, or a const that my library never takes the address of, the resulting .so will not change, and yet I can change my ABI by doing so.

We just ignore this for C, since distros do the work of making sure that C developers don't destabilize their own ABIs this way, but it's still an issue, even in C.

Defining the Rust 2024 edition

Posted Feb 1, 2024 14:33 UTC (Thu) by bluca (subscriber, #118303) [Link]

It is a Rust-specific problem, because I am talking of Rust-as-the-ecosystem, not Rust-as-the-language. It's only the corporate-driven ecosystems of Rust/Golang/Node that have this problem in reality. And that's because the corporations pushing for these ecosystems have no interest nor incentive in solving it, and don't care about the use case at all, they just assume someone will make it work somehow on their own time. This does not and will not scale, and at some point it will explode badly.