Defining the Rust 2024 edition

Posted Jan 30, 2024 16:10 UTC (Tue) by bluca (subscriber, #118303)
In reply to: Defining the Rust 2024 edition by farnz
Parent article: Defining the Rust 2024 edition

There are binary modules for Python and Perl too. You don't have to recompile the universe when one of those changes. And even if there weren't any, so what? The point is that those ecosystems are manageable by distributions, while Rust and Golang are not. The "how" is irrelevant in that comparison.

Defining the Rust 2024 edition

Posted Jan 30, 2024 16:18 UTC (Tue) by farnz (subscriber, #17727) [Link]

That's not my experience of maintaining a binary module for Python in a distro - I have to "recompile the universe" (in as much as I have to recompile the universe for Go or Rust code) every time something changes in the distro. It works, because (like a lot of packagers), I'm putting in the effort to make sure it's not hard to recompile the world when a dependency changes, and I'm doing the work to get those recompiles to happen, but it's not "free" at all.

Effectively, what you're saying is that because people put a lot of work into Python and Perl, but not NodeJS packages for distros, Python and Perl are fine, but NodeJS is a problem because no-one's willing to put the work in to maintain distro packages when npm works just fine for them.

Also worth noting that Fedora has had someone (mostly Fabio) do the work to make it easy to package Rust in Fedora. It's thus fairly trivial to maintain a Rust package in Fedora, because Fabio and a few others have made it easy.

Defining the Rust 2024 edition

Posted Jan 31, 2024 9:00 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (10 responses)

Because the binary modules use a C ABI and, when they need to talk to each other, generally do so in Python code or with their own runtime linker; the latter option is only viable in turn because the languages are very much runtime- and duck-typed. And it's such a pain that usually you let Cython write code for you rather than use C.

You can do the same in Rust. Let the crates export a stable C ABI that can be used for dynamic linking. That's how librsvg works and in fact it's also how it's often done for C++, see for example libclang (though that didn't prevent them from breaking ABI by mistake at least once).

Defining the Rust 2024 edition

Posted Jan 31, 2024 11:39 UTC (Wed) by bluca (subscriber, #118303) [Link] (9 responses)

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.