* a CLI tool
* a backend service
* a plugin to an existing tool
* an HTTP API / web app
You will note that a basic CLI tool requires nothing but arg parsing to get started, no complicated library or abstraction layer, while as you advance in the list above, you will most certainly use more libs and less of the raw language constructs.
Also, in the case of Rust and other compiled languages, ease of distribution as a binary rather than a package or some form of arbitrarily complicated installation method certainly helps.
YMMV of course but this is my approach and maybe it explains a bit of the trend you're wondering about.
Gone are the days of packaging up distro-specific binaries, or worse yet depending on some system installed script interpreter (and all the myriad of ways it can be broken or out of date on your user's machines). Now you just download a single executable, put it in your path, and you're done. It will always work--today, tomorrow, ten years from now. It's so easy and reproducible you can even just commit the tools into your source repo if you want.
Honest question: As someone who knows C++ and CMake, what Rust and Go do to make it easier?
* you can reuse (parts of?) it in your project easily
* it will be fast
* you can contribute to it easily
But not to JS or Python, to be clear.
At least for rust (I'm not as familiar with Go), it brings super easy project setup and library inclusion.
E.g. for creating a project and running it:
> cargo new my-cli > cd my-cli > cargo run
And then all I need to do is add structopt to the cargo.toml file to bring in a command line parser with hygienic macros.
Edit: they also do static linking by default :EndEdit
‐---------------------
But what it really makes easier is not needing to worry about memory safety. C++ is good at making static binaries, even if it might be slightly more fiddly.
So it's more like the static binary is the advantage over scripted languages, and memory safety is the advantage over c++.
I would never attempt a tool in c++ now that I know Rust.