Defining the Rust 2024 edition

Posted Jan 31, 2024 10:29 UTC (Wed) by matthias (subscriber, #94967)
In reply to: Defining the Rust 2024 edition by LtWorf
Parent article: Defining the Rust 2024 edition

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