General Programming Discussion

7758 readers

8 users here now

A general programming discussion community.

Rules:

Be civil.
Please start discussions that spark conversation

Other communities

Systems

Functional Programming

Also related

!opensource@lemmy.ml

founded 5 years ago

MODERATORS

Cloak@lemmy.ml

Restioson@lemmy.ml

How do modern languages deal with prototyping and modules internally? (lemmy.ml)

submitted 2 weeks ago by velox_vulnus@lemmy.ml to c/programming@lemmy.ml

6 comments fedilink hide all child comments

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 #include <gtk/gtk.h>, 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?

you are viewing a single comment's thread
view the rest of the comments

[–] JoYo@lemmy.ml 1 points 2 weeks ago* (last edited 2 weeks ago) (1 children)

go has an abi, if unstable between versions.

https://pkg.go.dev/internal/abi

rust foundation has stated that they will never have an abi.

I think both and zig support C ABI. Because Rust has no internal abi, projects will always be structurally incompatible with dynamic loading. that leaves rust with FFI.

[–] Ephera@lemmy.ml 2 points 2 weeks ago

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.