On 10/20/22 10:01, Neal Gompa wrote:
On Thu, Oct 20, 2022 at 9:39 AM Kevin Kofler via devel
<devel(a)lists.fedoraproject.org> 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)