On 10/13/22 11:18, Kevin Kofler via devel wrote:
Fabio Valentini wrote:
> Do you have suggestions for improving this situation? I think we're
> pretty close to doing the best we can with packaging Rust projects,
> given the current limitations of the language (i.e. the support for
> building "true shared Rust libraries" is still very limited and
> unstable; but that might improve in the future).
Building true shared libraries is pretty much a prerequisite for any sane
form of packaging.
I strongly recommend that you bring this up on the rust-lang Zulip
(
https://rust-lang.zulipchat.com) and see if you can find people who can
improve this.
> Additionally, the way the Sequoia GPG backend for RPM is
implemented,
> it's actually shipped as a standard shared library with a C ABI and
> accompanying C headers (which are binary compatible with the existing
> in-house GPG backend code in RPM). No Rust code will be statically
> linked into /usr/bin/rpm.
That at least makes sense. (Though I assume that that C-style .so still
internally depends on a whole bunch of Rust crates that are statically
compiled and linked into the .so, does it not?)
It does.
> I'm sorry to disappoint you, but Rust is here to stay,
whether you
> like it or not.
> For example, it's been voted the "most loved" and "most
wanted"
> language for a few years in a row in Stack Overflow's surveys:
>
https://survey.stackoverflow.co/2022/#technology-most-loved-dreaded-and-w...
And according to the same statistics, the majority of developers runs
Windows, yet hopefully you do not propose that Fedora ship Windows…
We need to ship what we can reasonably ship, not what the (relative)
majority of developers in the world (most of whom do not even run Fedora)
happens to prefer.
There is now Rust code in the Linux kernel. It currently is not
needed by any shipping driver, but that is not a matter of *if*,
but of *when*. The Asahi GPU driver is being written in Rust,
for example, so anyone building Linux for Apple Silicon will need
CONFIG_RUST=y in the not-too-distant future. systemd (yes, systemd)
is considering using Rust, though it has not yet started including it,
and there is already Rust code in Mesa IIRC.
C and C++ are being moved away from because they have unfixable
security problems. Memory unsafety, which is predominantly (though
not exclusively) found in C and C++ codebases, accounts for well
over half of all security vulnerabilities. Google tried to retrofit
memory safety into C++ and failed, and the existing methods for
making C memory-safe either have massive overheads (4x slowdown
for a single-threaded application, worse for multi-threaded, IIRC)
or require a completely unreasonable amount of developer effort for
a volunteer project (formal methods).
--
Sincerely,
Demi Marie Obenour (she/her/hers)