Hacker News Reader

Comment by flukus | Hacker News Reader

Binary compatibility. As a developer I want to be able to:

1. Write an app in rust.

2. Use a rust library in that app, via the native rust interface (using c interfaces negates a lot of the pros of rust).

3. Dynamically link that app to the distro repository version.

4. Have the distro apply security updates to that library without recompiling my app.

5. Ignore cargo completely.

As a user I want to:

1. Not download and install multiple copies of common rust libraries (as is the cargo norm).

2. Not be in doubt whether a particular application is using the latest patched libraries.

It seems that rust community has learned from the mistakes of c, c++, and java. But they failed to learn the successes as well.

View on HN

While your use cases are definitely valid for you, this is not a Rust issue, but something that's 100% decided by your distro. They decide if, when and how they integrate Rust into it.

As for the multiple copies issue with Cargo: I generally agree with you that this definitely feels like 1 source of major blow up in project compile times, and it would be nice and useful if that were reduced as much as possible. But there is a reason that this system is in place: each crate defines how it compiles and consumes its dependency crates, so if crates A and B both depend on crate C, then A might compile and consume C differently than B does. This results in effectively different libraries once compiled, and ATM there is no way to predict in advance what the effect of any given compile flag will be since any flag can switch on/off arbitrary code. Hence Cargo keeps A's C dependency separate from B's.

Then there's the not doubting whether an application uses the latest patches. Up to a point, this can be automated through exploitation of SemVer: if Cargo could figure out that a new library version is API and ABI compatible with the previous version then I'd argue that Cargo should perhaps just auto-update it. A bigger issue is what happens when a new major version of the library is released, as those tend to break APIs in order to perform maintenance. That is something that as of yet has not been automated.

> While your use cases are definitely valid for you, this is not a Rust issue, but something that's 100% decided by your distro. They decide if, when and how they integrate Rust into it.

It's a rust issue because it's up to the rust compiler to generate ABI compatible binaries, at the moment there is no ABI so there isn't much distros can do. It seems they have no intention of adding one any time soon: https://github.com/rust-lang/rfcs/issues/600

This is why system libraries are nearly always in c and not c++. The ones that aren't (Qt) have a long history of broken language bindings.

This is not as much as a problem as you believe. Rust is perfectly capable of making objects that have a C API and ABI precisely for this reason, and the most popular distros only work with supported compile targets anyway. That said, a distro like Debian might indeed encounter some issues at this time for the less prominent platforms eg MIPS or PowerPC based chips. That shouldn't prevent Debian from including Rust altogether though, they merely should exclude it on those less or even unsupported platforms.

Reply on news.ycombinator.com