On 10/20/22 10:01, Neal Gompa wrote: > On Thu, Oct 20, 2022 at 9:39 AM Kevin Kofler via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: >> Rust needs to adapt to become relevant in GNU/Linux distributions. >> > > There is nobody pushing for Rust to improve anymore. When Igor and I > were building out Fedora Rust, we did some engagement with Rust > upstream about stabilizing Rust's ABI so we could ship dynamic > libraries. While one or two members of the Rust core team were > sympathetic, most of the Rust community attacked me for "trying to > make Rust like C" and I got crap from people on the Rust community > channels, Twitter, and other places. Eventually, I flamed out because > there's only so much punishment someone can take over it. Personal attacks are not okay. > A couple of years ago, there was a revival of the topic[1], but it > went nowhere again. > > Until the situation changes, I'm very firmly anti-Rust. Unfortunately, > sometimes I have no choice but to deal with it. > > [1]: https://github.com/slightknack/rust-abi-wiki There are a couple major constraints that apply to Rust: 1. Rust implements generics via monomorphisation. This means that e.g. Vec *has no ABI at all*: code will only be generated for Vec<T> when it is instantiated. 2. Rust relies heavily on cross-crate inlining to get good performance. If e.g. Option::map is not inlined into the caller, performance will be terrible. Neither of those constraints are unique to Rust. C++ template libraries have exactly the same problems. It’s just that we think of C++ headers as being the interface to a library, instead of the implementation. Trying to ship the implementation of types like Vec and Option in a shared library makes no more sense than doing so with C++’s std::vector and std::optional, which is to say, none at all. Another factor is maintaining a stable ABI severely limits library evolution. In C++, ABI stability has resulted in std::regex being *far* slower than third-party regular expression libraries. I am not surprised that Rust wants to avoid similar problems. -- Sincerely, Demi Marie Obenour (she/her/hers) _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
