When you're working in a GCed language you assume your language's GC is responsible for freeing memory. When you interoperate with a language where owners are responsible for freeing memory, you have to have a way to "disown" structures you've created but passed into the ownership language (e.g. a callback you've passed to a library function) so that your GC doesn't free them, and a way to "own" structures you've received from the ownership language (e.g. values returned from library functions) so that your GC does free them, and neither of these things will be easy/natural in your language.

When you interoperate with another GCed language it's even harder, virtually impossible, because both languages' GCs assume they own everything and so anything that's visible in both languages will be freed twice.

Well, declaring untraced references in Modula-3 or Active Oberon, or doing native heap allocations in Nim, D, Java and C# is relatively simple.

Using GC languages doesn't mean doing 100% memory allocation via GC.

I've done it in Java; it's not officially supported in the language standard (or has only recently been added if so - certainly they were talking about it for years), and the wider language does not generally have the support or idioms you would want (e.g. try-with-resources was only introduced a couple of versions ago), libraries aren't oriented towards that style.... It's certainly doable but I'd stand by it not being easy or natural.

Although I mentioned Java, due to ByteBuffers and Unsafe, it is clearly not the best one of the set of languages that I mentioned.

Others on that list have specific language features for GC free allocation.

Languages interfacing through an ABI implicitly need to agree on their memory models, calling conventions, exception unwinding, etc.

There's lots of detail in the D language garbage collection docs:

https://dlang.org/spec/garbage.html

The whole thing might be instructive, but 28.3.3 has a bunch of particular expectations of the D GC.

Because you have to add support for GCing of foreign structures from these libraries, or keep the interface low-level and force the user of the GCed language to manually manage these foreign objects. Adding support for GC can be difficult if not impossible, because GCs often arrange memory in special ways (different pools, etc.) whereas the foreign library probably just uses malloc.

What I meant was: If language X needs a GC, then writing a library in X makes it difficult and very inconvenient to use that library from another language.

The comments of jonathanstrange and humanrebar are also spot-on.