2026-10-26 16:35 UTC
ABI-compatibility is only relevant when we talk about binary libraries… if I were talking about user programs then it would be the API what matters, not the ABI.
“a lot” of dependencies is a fuzzy line to cross… most projects start small, then as they grow they might modularize more and more, attempt to de-duplicate efforts, etc. So I feel you’d end up essentially duplicating what cargo is already designed to handle.
As I said before: your approach might work if you just want to use a little bit of Rust included in a C project… or if your Rust project is small and does not have many dependencies… but the moment you start relying in more and more components and the dependency tree grows enough, it’ll become hard to manage.
Replies (1)
-
@thingsiplay@lemmy.ml 2026-10-26 16:40
But that is the suggestion here, to not rely on many dependencies. And currently this is an odd thing to do in Rust, because there is no other support or eco system to support this kind of building. Yes, if you want rely on man dependencies and crates io, then it makes no sense to go that route I suggest. But this would only work widespread if distributions would adopt this kind of packaging and providing a stable environment. Imagine Python wasn’t installed by default on Linux, how would anyone think of relying on it? I know it’s technically not the same thing, but I’m making a comparison for having it in the distributions repository (or installed by default), not how the language works.