My problem is honestly that Cargo has spoiled me. C (& C++) may indeed have more libraries; but adding them to a project is a non-trivial exercise.

Assuming your project subscribes to the "build it with one command" philosophy then:

- You'll need to install the target project's build system

- You'll need to invoke that from your project's build system

- You'll need to copy those artifacts (which depends upon implementation details of their build system) to the right output directory (which depends upon implementation details of your build system.)

- Then finally you get to include the headers complete with ifndef guards. (Honestly it's getting increasingly more difficult for me to even tolerate C/C++ header files.)

- P.S: probably repeat this list for every target platform you build on.

---

When installing a package takes a single line of configuration, or a single command, I am far more likely to ignore my "not invented here shoulder-demon" and just add a 3rd party dependency. In C/C++ I actively avoid adding dependencies, regardless of how numerous they may be.

(This link will change in one or two releases; I landed a new "Unstable Book" a few days ago.)

The TL;DR is Rust expects certain stuff to be implemented in Rust code to work, and that's provided by the standard library. When you don't use the standard library, libcore implements all but a few of them. Implementing them is not yet stable.

https://github.com/rust-lang/rust-roadmap/issues/15 is the roadmap item for some things relating to this; id you want to chime in with your pain points here, that'd be very helpful!

Rightfully? People resort(ed) to "C with classes" to make C++ tolerable and/or reliable.

If anything, it's the opposite: when most people complain about C++ it's about C++ itself, the full language, and its whole baggage of features and their obscure interactions and intricacies. Not about using C++ as C with classes.