There are fundamental semantic differences between the languages. An immutable language will always have a serious impedance mismatch with a mutable library. A library that uses GC won't work in a language without them, a specific example of the general principle that memory management strategies vary widely. A library that uses dynamic types will have a huge conversion boundary with a statically-typed language, and vice versa. A library that uses threads, or expects threads, will have a hard time working in an event-based environment that depends on code voluntarily yielding to maintain its responsiveness. A language that wants to provide guarantees about correctness or whathaveyou is forced to give all those up to talk to a lowest-common-denominator library.

And that's just the top-level differences. It gets worse as you get into the details of API style and the costs of the indirection layers to convert into the local style, assuming conversion is even technically possible.

Even if you write with the lowest possible common denominator of C or Rust with no runtime, you'll still encounter a significant subset of those issues. And of course we still will use such things; all serious languages can communicate in some manner with a C implementation of a library. (Not for any theoretical reasons, really, C has more opinions than people often realize, but because it's still the baseline current systems are built on.) But it can't be as good as a native implementation.

>you'll still encounter a significant subset of those issues

Heck you will encounter those issues in a large project using only one language!

> This brings me to a question I have had for a while, why do we even have so many language specific libraries for common tasks instead of more "universal" libraries with bindings for each.

A lot of language specific libraries incorporate foreign language (often C) libraries and add additional functionality thst fits the ergonomics of the target language, rather than being a thin wrapper around a language neutral library. This is more than aesthetic when the target language has, for example, differences in type system or fundamental guarantees from the underlying library's language.

OTOH, sometimes there aren't C (etc.) libraries, and it's more straightforward to implement a library in (say) Python. But once you have a Python library, calling into it from Rust, C, Erlang, or even a broadly similar language like Ruby is, to put it mildly, non-trivial.

Languages usually have a foreign function interface (FFI for short) to interface with external libraries. That's not as easy as one could expect, even for languages that are "closer to the metal": I remember Pascal and C different parameters passing conventions, left to right vs right to left and the cleaning of stack... you need to use compiler directives and careful thinking. Also which memory manager you use and the fact that DLLs might not "see" the same address space.

You mention Python that they say has an easy FFI with C. That's nice but it's usually used for the performance more than for reusing code.

Well, we do have some programming tasks that are almost exclusively performed through bindings on different platforms (cryptography, graphics/GUIs, scientific computing to some extent), but the hassle of maintaining bindings is enough that the “need barrier” is high: a given library has to be doing really important stuff that is also really hard to reimplement to end up in the set of tools that are almost always used via interop/bindings. This indicates a deeper problem hidden in your question: for a bunch of reasons (technical, personal, OSS-community-political), maintaining multi-platform bindings is a hassle. Things like Truffle/Graal aim to solve that by providing a common binding “middle” layer in various platforms’ runtimes. Things like libffi offer ways to make ad hoc binding easier. It’s a complicated problem.

This is exactly the case with JVM languages today: Every language has its own idiomatic abstractions, but everything is ultimately based on the underlying Java libraries.