Defining the Rust 2024 edition

Posted Jan 30, 2024 13:10 UTC (Tue) by LtWorf (subscriber, #124958)
In reply to: Defining the Rust 2024 edition by khim
Parent article: Defining the Rust 2024 edition

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).