I don't think this is the right way: interop with the C ABI, and for the hercules who want to do that with c++, should be native to such programming languages, not from a project on the side.
Agreed. And I think approaches like python or node, where you need to write some c code against their API, is getting it wrong also. The most smooth interop experience I've ever had is with c#. You just export normal c functions from a dll, and the c# code can call it. All the awkward bits like "how do I marshal a string" happens in the host code, not the native module. The overall experience of that is soooo much better. It also has the added benefit that if you just want to load a third party dynamic lib and call a few functions, you don't necessarily need to write any native code at all. You can just... do it. Then you don't need to set up a native build system, etc. It's really, honestly superior.
Are you sure python needs that? I heard about c-type.
A python native module may be providing python semantics on top of a dynamic library (libressl), but if some python code decide to dynamically load the shared library to make direct C ABI calls, I guess this is built-in, isn't it?
It’s highly context dependent. I’ve used stuff like Swig before now to create code that can be shared between multiple different environments. In that scenario the more host side code you’re writing the less effective your solution.
It is. Python, Java, etc have built-in ways to interface with native code. SWIG is a framework which sits on top of those, and aims to make it easy to do that interfacing across multiple languages.