I'm also not fond of making the package manager also kinda the build system, but that's just my preference to keep it flexible.
Linking to a library from another language is rather considered an 'edge/complex case' in most circumstances outside of systems programming and the lib having a C API. And that case is literally three lines of Rust in build.rs if you use e.g. bindgen.
While Rust is a systems programming language the primary use cases, judging from the ecosystem of crates, are actually /not/ drivers or desktop apps. The latter are an 'edge/complex case' that just happens to be also nicely covered.
And not doing that (i.e. operating solely inside the language ecosystem) is what most users of such ecosystem would reserve the term 'basic' for.
To understand where I'm coming from: would you consider 'linking' to a Python or Erlang libray from C++ 'basic' or an 'edged/complex case'?
* 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).
I feel like the problem is that it isn't just a package manager... it insists on simultaneously being not only "a" but "the" build tooling, which is trading way too much flexibility for a very small amount of convenience. And like, OK: maybe this is useful for people who are just getting started, but I would firmly argue that this kind of tooling should consider the needs of the expert and not make severe tradeoffs for the needs of the beginner unless it is trivially and obviously optional and there can be growth through changes in tooling (where maybe people "graduate" from Cargo to a more extensible tool... but since it is also the package manager, that's brutal).
The issues for the tool are then riddled with bugs that have been open for years (I think some of the ones that I've been blocking on might already be at 5 years, which is shocking to me as I don't even think of it being very old) that even often have multiple reasonable pull requests filed but where no progress ever gets made on fixing the problems because, even though it is often trivially shown that there is no way to use the tools correctly currently in the general case, they insist that the behavior of a working tool might break some theoretical user relying on the current inconsistent set of behaviors.
The result of all of this is that there are a ton of workarounds for Cargo that projects have started to have to embed almost as boilerplate into their projects, including a popular one that is going around right now (required for Linux->Linux cross) involving setting an environment variable that explicitly tells the user not to set it ever in the name of the variable but like... Cargo doesn't be have any other way of making this stuff work correctly. It is honestly infuriating and ridiculous and there are good reason why you keep seeing stuff like Google avoiding it entirely as part of their Bazel integration.
> setting an environment variable that explicitly tells the user not to set it ever in the name of the variable but like... Cargo doesn't be have any other way of making this stuff work correctly.
This has nothing to do with Cargo, if you're talking about RUSTC_BOOTSTRAP. This is because the kernel would like to use a stable compiler, but unstable features. This isn't a supported build configuration; the environment variable is an escape hatch for the bootstrap process, and isn't intended for nothing more. It would be, imho, unreasonable to expect Cargo to support something that is explicitly not intended to be supported.