why rust libraries may never exist.

Rust libraries may never exist. Sure, I know what you're thinking: sure they do. In cargo. Well... it's not what you think. In this video we talk about why Rust libraries may never actually exist, and what we can do about it.

🛒 GREAT BOOKS FOR THE LOWEST LEVEL🛒

🔥🔥🔥 SOCIALS 🔥🔥🔥

[ikhlasulkamal]

You could have said "Dynamic Library", i genuinely thought Rust Foundation messed up something big again about Libraries in Cargo like they did about the brand / logo last time.

[emty]

ELF ABI isn’t actually a term. The ELF Format supports multiple ABIs, for example my gcc compiler uses the System V ABI

[tinrab]

It's important to point out that compilation is only long on clean builds. Incremental builds are okay-ish, during development.

[arjentix]

Btw, unsafe Rust code does NOT disable borrow checker. It allows unsafe function calls, raw pointer dereference and stuff like that, but does not disable borrow checker

[maxniederman]

FYI, Rust *absolutely does* have support for dynamically linked libraries, including all Rust features. The problem is that the ABI is unstable across compiler versions, not that it doesn't exist.

[leshommesdupilly]

- Wait ?? It's all C/C++ ????
- Always has been *error: no matching function for call to ‘typename std::remove_pointer<typename std::decay<typename int>::value, int>::type>()), int>::value), std::remove_reference<const int&>::type>::type)>::value, int>::type>(), int>::value), int>::value)>::value, int>::type>(), int>::value), std::decay<typename int>::value)>::value)>::type>::type)>::value), int>::type>(), to ‘int’*.

[Xeverous]

Wait. C++ has the same problem and solved it in a pretty clean way: just encode type information in the ABI data. If you disassemble C++ library objects, you will notice that symbol names aren't clean function names from code and contain a lot of encoded information (such as constness of objects, calling convention and other). This technique is called name mangling. Can't Rust do the same?

And regarding templates (static polymorphism): same state in C++ as in Rust: reevaluate every time and recompile. That's one of the reasons you still need header files for compiled libraries. Some libraries in C++ are so template-heavy that they go header-only and can not be built by themselves.

[navirc]

"if i pass a mutable reference into a compiled binary, how is it possible for the borrow checker to make sure the reference is used in a way that is safe"

the borrow checker would've already made sure of that when the library binary was compiled, then, the checker in your code would look at the function signature to enforce the rules at your side. if both sides were checked individually, and the interface contract (function signature) is respected, it should just works as if you checked them at the same time

[mr.togrul--]

Didnt Google gave million to the Rust Foundation to improve C++ Interoperability, I think many more will ask and maybe donate to the Foundation to make devs there focus on this, so in near future i wouldn't be surprised to see good or somewhat good alternatives to improve this

[Wadu]

Over in WebAssembly land, they're working on something you could call an "ABI" with the Component Model, where the interface a component (=library or application) imports/exports is defined in a separate file (a .wit file), and then bindings from that file are generated for whichever language the component is written in (C, Rust, Go, ...). If other libraries or applications then want to use this component, they also generate bindings for their language from the same .wit file.

[hallkbrdz]

IMHO the original K&R C was essentially a super macro assembler. A way to code in a higher level format, using a compiler for the parts that weren't that time sensitive, and in-line assembly code for those parts that were.

[brady]

I don't see why the borrow-checker would not be able to work across boundaries for other libraries written in Rust. If the functions within the Rust library violate borrowing rules then the library shouldn't compile in the first place, right?

[FalcoGer]

@1:00 easy solution: c++ instead of c. use smart pointers and std::array over manual memory management and c-arrays, and you wipe out 95% of memory issues.

[BogdanSerban]

Shared libraries are one of the worst things that ever happened. I remember when we used to compile linux programs from source and you'd get a ton of errors since libraries weren't compatible. Or when a Windows app needs a specific dotnet version because they're not backwards compatible. Having an entire app package makes the most sense.

[stanieldev]

Looks to me that this is just Rust being relatively new. C has had decades to try and perfect itself.
I can't wait to see what they do with Rust, since it is unironically one of the best languages I've ever learned.
That or someone makes a language like Rust that works around the mistakes mentioned.

[Nuclear]

In short:
1. rust does not have a stable ABI
2. Using shared libraries will break the static safety analysis.
These things make shared libraries impossible in rust.

[hansdampf]

It’s is totally possible to put rust libraries in their own shared objects and link them at compile time. The problem is that the ABI isn’t stable across compiler versions which limits the usage of those libraries by a lot.

The only application I can think of for this is an embedded OS environment with very limited ram where you can set the rust compiler of a project to a fixed state and compile one shared object that you use across projects. This way the shared object is only loaded once into memory

[mmstick]

I've made dynamic libraries in Rust multiple times. These days you can easily reach for crates like stabby and abi-stable. The bigger question is why you would want to do that when static linking is better in most cases.

[twenty-fifth]

You could say that binary interface is a bit.

Rusty.









; )










WHY ARE YOU BOOING ME I AM RIGHT?!

[shaurz]

Even C++ has problems with ABI. GCC has in the past had to revise the C++ ABI in backward-incompatible ways. C will probably remain relevant as long as shared libraries are around.