Defining the Rust 2024 edition

Posted Jan 31, 2024 11:39 UTC (Wed) by bluca (subscriber, #118303)
In reply to: Defining the Rust 2024 edition by pbonzini
Parent article: Defining the Rust 2024 edition

Except you can't really do that in Rust, as even the standard library doesn't do that, so what's the point? The default is not to export a C ABI, is to use the internal unstable APIs across dependencies.

Defining the Rust 2024 edition

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

It's not the default but you can do it, and it's a good idea if you want the library to be consumed outside the Rust ecosystem—which, I will grant, is usually not a priority for Rust developers.

Defining the Rust 2024 edition

Posted Jan 31, 2024 13:22 UTC (Wed) by bluca (subscriber, #118303) [Link] (7 responses)

What does it matter if there's some obscure way to do it, but it's never actually done? The standard library doesn't do that. It's completely pointless.

Defining the Rust 2024 edition

Posted Jan 31, 2024 14:25 UTC (Wed) by mb (subscriber, #50428) [Link] (6 responses)

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.