Defining the Rust 2024 edition

Posted Jan 30, 2024 12:18 UTC (Tue) by bluca (subscriber, #118303)
In reply to: Defining the Rust 2024 edition by khim
Parent article: Defining the Rust 2024 edition

They do benefit from that ability, enormously so, by making it possible for such software to be available, easily and by default, for a large number of users of distributions. If said ecosystems don't _want_ to be shipped in distributions, because they are fine with making their users "wget | sudo bash", that's also fine, then they should clearly say so, so that any attempt to do so can be halted and time can be spent for better and more useful purposes.

Defining the Rust 2024 edition

Posted Jan 30, 2024 12:48 UTC (Tue) by khim (subscriber, #9252) [Link] (5 responses)

AFAICS said community is like a Java community, Python community or any other language community.

As in: if distributions want to do something — they may do the work and present the results for discussion, if distributions don't want to do any work — then it's not Rust fault.

> If said ecosystems don't _want_ to be shipped in distributions, because they are fine with making their users "wget | sudo bash", that's also fine, then they should clearly say so, so that any attempt to do so can be halted and time can be spent for better and more useful purposes.

They are ambivalent. If distributions want to ship something and, more importantly, want to support something — then it's fine, if they want to dump support on the mainstream community — then it's less than fine.

After all when some rust package breaks in Android you don't go and ask on Rust forums about how would you go and fix Soongs .bp files, you reproduce trouble with Cargo first. Why distros should be any different?

Defining the Rust 2024 edition

Posted Jan 30, 2024 13:10 UTC (Tue) by LtWorf (subscriber, #124958) [Link] (4 responses)

The distributions are in fact doing the work, despite the best efforts of rust developers. But are having to spend much resources to compile rust due to the lack of shared libraries, and loops in the dependencies.

You being unaware of the work being done is not the same as no work being done.

Defining the Rust 2024 edition

Posted Jan 31, 2024 10:29 UTC (Wed) by matthias (subscriber, #94967) [Link] (3 responses)

I do not see why not using dynamic linking necessarily takea much more resources. The only additional step is the static linking at the end of the build process. Everything else should be the same.

Rust should be able to use a global cache for build objects. So there should be no need to compile the same code twice. If you build statically linked C-code, you also reuse the precompiled libraries and do not recompile the libraries for every executable you build.

Defining the Rust 2024 edition

Posted Jan 31, 2024 10:32 UTC (Wed) by mb (subscriber, #50428) [Link] (2 responses)

It's not that simple in languages like Rust which do monomorphization.
A compilation of a library will result in different code depending on what types the user program uses.
Of course, it can be done if the library restricts itself to trivial ABIs like C.

Defining the Rust 2024 edition

Posted Jan 31, 2024 10:50 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

So basically, you're saying the use of monomorphisation necessarily uses much more resources, because the library has to be repeatedly compiled, once for each user program?

In other words, the source may be a library, but the object most definitely isn't.

So what we clearly need - Cyberax's comments about binary libraries aside - is a manifest which says "this is the ABI of this library" and declares all the types it exports.

I can see various problems with this approach - types defined in the user program, call-backs, etc. But it will satisfy a LOT of dynamic linking requirements, for a lot of libraries. Probably not all ... (sounds to me like those libraries I've seen mentioned that are just a dot-h).

Cheers,
Wol

Defining the Rust 2024 edition

Posted Jan 31, 2024 14:21 UTC (Wed) by mb (subscriber, #50428) [Link]

Almost everything is statically dispatched in Rust.
Functions are monomorphised per actual type (not per user program).
The actual types must meet the constraints.

I think that's not that much different from C++ templates, except that Rust adds strict constraints.

But I must say that I don't know how all this currently works in Rust dylibs.

> I can see various problems with this approach - types defined in the user program, call-backs, etc.

constraints will restrict what types/traits can be used.
But it's possible that a program can implement a foreign (exported) trait on an own type. That can be restricted by "sealing" the trait (Rust speak for making a trait un-implementable by code outside of the library).