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?
To my knowledge, they generally don’t. Shared libraries are a massive pain from a programming perspective, so it’s largely been avoided (even though there are some advantages for Linux distro maintainers and sysadmins).
Modern languages usually bring along their own package manager, which downloads the libraries you want to use from a central repository and then bundles them into your build artifact that you hand to users.
In ‘semi-modern’ languages, like the JVM languages and I think also Python, you get the dependencies in a folder as part of a larger archive.
With Go and Rust, they decided to include those libraries directly into the executable, so that many programs can just ship a single executable.