In my journey to learning C, I’ve come across header files, which are used to (I’m assuming) define a prototype for the source file, as well as structure modules. This feature, in my opinion, is pointlessly not just redundant, but possibly a source for pitfall. The same information can probably be extracted from the source code, if not for the restrictions of the language specification in C.
Say, if I have a GTK project, I will have to use the preprocessor directive, that will require the use of GTK headers that look something like , and they’re usually in the system path. How do modern languages, like Rust, Zig or Go deal with this situation, where shared libraries are used?
Ah yeah, I guess, my interpretation of that quote wasn’t quite right.
You can build a shared library in Rust, but it will need to be called via the C ABI or the WebAssembly ABI.
It is also possible to call a C ABI library in Rust (and virtually any other language), as well as a WebAssembly ABI library.
So, technically you can do shared libraries that way, but because the C ABI and WebAssembly ABI are significantly more limited compared to what you want to be passing around internally in Rust, you’ll only really want to use these in special cases.
Rust doesn’t particularly like dynamic libs. It compiles libraries you use on your dev machine, so it knows how you’ll use the libraries, which allows it to make various assumptions and optimizations.
For example, Rust can do generics via monomorphization (as opposed to vtables), which means it will generate the generic library code for each type that’s passed into the generic type argument. This is useful, because it can fully optimize that code, but also because it retains type information, despite the use of generics.