I can agree that it's not the most common case, but it's also out of necessity because there's multiple rust crates, for certain C & C++ libraries that are fund

I can agree that it's not the most common case, but it's also out of necessity because there's multiple rust crates, for certain C & C++ libraries that are fundamental in some domains, that either: * do not exist yet * struggle to provide full bindings * do not keep up * have stopped being updated One of the most glaring example for me is Assimp, which still does not have its Rust counterpart (and unsurprisingly, because Assimp has a weird interface to begin with). I didn't stumble upon bindgen, but from what I gather it's for library developers, not consumers, right? > the primary use cases, judging from the ecosystem of crates, are actually /not/ drivers or desktop apps Well, in that case (but not aiming specifically at you) why do I see so much claims that "Rust is the new C++"? > would you consider 'linking' to a Python or Erlang libray from C++ 'basic' or an 'edged/complex case'? I would consider it complex, but this is wildly different IMHO than Rust with C or C++ (but mostly C to keep it sane), which, while more "complex" than pure Rust, still falls within the reasonable expectations. The fact that there are so many crates wrapping around C (and C++ to some extent) libraries means that for the most part, that "complexity" has been offset by crates developers, but many Rust use-cases still seem to require a lot of C/C++ code to even exist (even if abstracted away by glue crates).