When people compare C++ with Rust, quite often the only thing measured is performance where depending in your cxx compiler Rust (or rather, llvm) may lose sometimes.

What is often forgotten is the ecosystem.

To build a cxx project you'll probably need to learn CMake and ninja; maybe Buck or Bazel too. If your project has eternal dependencies you may have to figure out yourself how tl link everything together using whatever build tools the authors were using. For docs, you'll have to learn and use doxygen; for style formatting, something like a clang-format and its presets and options; for linting, something like clang-tidy or cpplint, etc. For testing, probably catch2 or one of similar frameworks. There's no universal concept of "package" or "version", you're completely on your own here; most open source cxx repos that have dependencies just add them as git submodules.

In Rust, cargo build to build, cargo doc to generate docs, cargo test to run tests, cargo publish to push your crate to the index; cargo fmt to format the code and cargo clippy to lint it - that's it, we're done.

A large part of that is simply due to age, though. If rust were older it would have more baggage too, but also a larger ecosystem.

In my experience, Rust certainly has one of the easiest language ecosystems to use.

I've been using Rust for ~3 years now, and have been trying to learn C++, but I've been so spoiled by the entire Rust ecosystem's user friendliness that it's a very daunting task.

Or Makefile, or Meson, or autotools... And beyond to infinite.

Man, that type of stuff don't motivates anyone to learn a new language. If all what we should do it is code a solution and deploy with one command, oh God, will be a dream.

But no, beyond all this clusterfuck, by doing cloud stuff will be need probably Docker too, Kubernetes. Maybe ansible too? Oh, no, your team use terraforms.

D:

It's the Cambrian explosion in SW Dev tools. What amazes me though is how undead everything is. It seems that even ancient stuff is still somewhere out there waiting to be maintained. And there's a gazillion more every year adding to the pile.

Except revision control.

Would that a git for build tools would come along.

That is, something so compelling and sufficiently licensed that it quells the discussion in a jiffy so that the focus can be on getting work done.

There's something of a paradox to build tools - people like to have one in "their" language, but most languages are ill suited for it. Half of the people need something really simple. The other half need something extremely complicated. There's a mountain of edge cases, most of which people don't even notice, but which make other people's lives a misery.

For git, I felt kind of sad that "linus branding" helped it to beat out mercurial. git's UI is kind of monstrous (even linus admitted that). It's one of those rare technologies where a bad UI is branded as "you're just not smart enough to understand it".

To that point, the bun fight moved from the back end to the UI when git came along.

Personally, if you're not using magit[1], you should have a look.

Ridiculously powerful; check. Open source; check. Works like a champ in a terminal over SSH; check, check, check.

[1] https://magit.vc/

Magit is great! I use everyday. The more useful feature for me is partial staging by simple text selection. Help so much to create better atomic commits

Off topic, but anyway. I hate cmake, its overly complex and I can never remember how to do things with it. The thoughts of having to set up even a small cmake project has put me off starting new personal c++ projects. Its a headache I simply don’t want to have to deal with. I eventually gave up and started using tup for personal porjects. It doesn’t have the same support for prepackaged libraries, but I’m much happier and no lobger dread setting up new projects.

So, for me, its much worse than just “omg which tool, so many!” because the most used tool is also, in my personal opinion, terrible.

I suggest learning make. It is a wonderful language. Start with the GNU make manual.

When you find yourself manually listing the .h files that a c/c++ file includes, learn how to generate .d files (it is in the manual, but stack overflow has some better patterns).

Then, figure out how to use make to automatically generate the list of source files required to build each binary. At this point, your makefile will have surpassed the usability of cmake in my opinion.

Soon after that, you’ll think you need recursive make to deal with vendored dependencies. Instead, read “recursive make considered harmful”.

At that point, you’ll start to hit rough edges, but you’ll be well beyond a “small project”.

Next on my make reading list is the BSD ports system.

I’ve heard bazel is a decent make replacement, but I haven’t used it.

Ninja doesn’t aspire to be one, and cmake/autotools are the reason I decided to go with raw make in the first place.

I provide a simple Makefile for almost every project, mostly as a reference to myself and others. Add a "build", "clean", "deps", and maybe "install" targets and then regardless of the specific tooling/language it’s easy to figure out what to do or where to start. Even if that project/language has a good build system or scripts. Simple makefiles aren’t too much worse than yaml.

> (it is in the manual, but stack overflow has some better patterns).

I love how that's one of the things the author listed in their post :)

make is useful, when you stay within its confines.

However, it quickly turns into a morass the moment you want to do something outside of it.

I tried, and I gave up. I ended up coding something similar to make, in python. I just funneled some of my commands to the shell module.