Most commonly given "evidence" of that is writing a relatively complex tool using just a few lines of Rust... by using tens (or even hundreds) of 'crates' and just calling a few functions from all that, and calling it a "few-functions program" that does wonders. That is completely disingenuous. All it shows is that Rust has grown a relatively large "ecosystem", which isn't bad per se, but doesn't mean anything more than "it has gotten traction".
And, this excessive reliance on third-party code, which Rust promotes more than almost any other language I've seen (the number of crates a given program is dependent on, from all Rust code tools I've seen so far, is by far the highest I've seen with any other language), may look like a huge benefit, but is also one of the biggest issues in software development there are today, leading to bloat, relying on third-party code nobody has cared to even check, etc.
As soon as one fails to look at the bigger picture, everything looks rosy in the present and sour in hindsight.
I was thinking maybe josfemova meant the absolute classic "X is easy to do by calling an external implementation which does X, therefore language which calls X is simple to use". Which of course works with any language which can call external implementations, including C or even assembly.
But I wanted to give josfemova benefit of doubt, maybe they mean some feature of the language itself. But apparently no. What a joke.
Anyway thanks for the explanation, so this makes Rust a total and utter joke, it's a no-go. You might be able to use it if you went against the flow and avoid the "ease" of importing work by others, but if it encourages bringing in "easy" libraries then that scares the shit out of me. As the xz security disaster demonstrated, we already have too much dependence on library code. Even the sshd folks had no resources to follow the dependency chains sshd->libsystemd->libxz to find the backdoor.
This "easy" library bloat programming might be all fine for userland applications on general purpose computers, e.g. desktop applications and games, as it widens the pool of available programmers and reduces time-to-market, but no-go on embedded, OS kernel and security critical core tools even if on userland.
So Rust is clearly new Python, "oh look how easily I can do this and this and that" (by calling an existing implementation which does it all for me, written in C). Or Arduino, "look how easy it is to buy ready-made hardware and software and press a button".
But someone has to do those implementations, and this is called embedded engineering. Clearly Rust has no and will have no place in it.
Working in a field where we have firmware part, backend part and UI part, pretty much everything else is a moving target except the firmware. Everything else requires maintenance when third party code changes. The firmware is the only one which just keeps working. Amount of external code is minimized and that is brought in as source code and compiled in, so that it can be modified and bugs fixed. The last thing I want to bring the same uncertainty into firmware.
Rust is bait&switch. The claims are about memory safety and better handling of low-level hardware stuff in general, or "embedded C replacement". The lure part is, seemingly, ease of development for young players by using existing code. The result is opposite of safe low level language; just another new general-purpose easy-to-use new language, like Java or Python, which beginners will tout all over the Internets.