Packaging Rust for Fedora
Packaging Rust for Fedora
Posted Oct 30, 2022 13:31 UTC (Sun) by ssokolow (guest, #94568)In reply to: Packaging Rust for Fedora by khim
Parent article: Packaging Rust for Fedora
No. It got calmer when C++ developers have decided: yes, we do want to support shared libraries. Rust developers have never done that.
Whether or not to build a cdylib from a Rust project is certainly a choice upstream makes, but also bear in mind in mind that, unless things have changed since 2012 on the ABI compatibility front, many of the core issues are just as unsolved in C++... it's just less idiomatic to rely on things like templates in C++ than on things like generics in Rust. (See The impact of C++ templates on library ABI by Michał Górny from 2012 for more on that.)
...not to mention, Rust's dependency counts are misleading when you're trying to make comparisons, because C and C++ are rife with bespoke reimplementations and single-header libraries that maintainers just take in stride, rather than trying to split out into their own packages. (See the Gotta go deeper section of Alopex's Let's Be Real About Dependencies for details on that.)
Posted Oct 30, 2022 14:50 UTC (Sun)
by khim (subscriber, #9252)
[Link] (3 responses)
No. The important thing is standard library. It's ideomatic to use it in both C++ and Rust. And while it's called Standard Template Library Swift as we all know picked different road, compiler-based. But, again: standard types and standard templates are usable when you build shared library. In Rust land… Rust developers have never done that and not even That means that shared-library-Rust doesn't even remotely resemble normal That's pretty big difference: while in C++ it's possible to write code which would be acceptable both in normal C++ project and in shared library, too… in Rust it's just impossible. Without ability to just return In C++, on the other hand, it's perfectly fine to accept
Posted Oct 30, 2022 15:02 UTC (Sun)
by ssokolow (guest, #94568)
[Link] (2 responses)
Posted Oct 30, 2022 16:51 UTC (Sun)
by khim (subscriber, #9252)
[Link] (1 responses)
There is no free lunch. Either you have ABI-stable standard library or shared libraries are, basically, impossible. And it's not as if Rust standard library can do sudden, radical, changes. It just wasn't in use for as long as C++ one.
Posted Oct 30, 2022 17:09 UTC (Sun)
by ssokolow (guest, #94568)
[Link]
> it's just less idiomatic to rely on things like templates in C++ than on things like generics in Rust.
Packaging Rust for Fedora
libstdc++ developers have decided that they would find a way to make it work as shared library. And they did. Yes, templates are injected in your code, not in the shared library, but certain discipline on the side of libstdc++ developers made it possible.core is offered in a way suitable for use in shared libraries.std-based Rust. While in C++ the part which can be used as shared library is very much a subset of what you would do in normal C++.Result or accept Option your code is not Rust, it's different language.std::option or pass std::unique_ptr even in function which is part of shared library.
Fair point... though an argument has also been made that C++'s focus on ABI stability is killing the standard library.
Packaging Rust for Fedora
Packaging Rust for Fedora
Packaging Rust for Fedora
There is no free lunch. Either you have ABI-stable standard library or shared libraries are, basically, impossible.
Or you marshal your data in some way, like the abi_stable crate does for enabling dlopen-able libraries using higher-level Rust constructs via Rust-Rust FFI through the C ABI.
And it's not as if Rust standard library can do sudden, radical, changes. It just wasn't in use for as long as C++ one.
The Rust standard library has two advantages over C++ on that front:
HashMap implementation for a vendored copy of a port of Google's SwissTable. There's currently a PR being refined to replace the internals of std::sync::mpsc with a vendored copy of crossbeam-channel.)