I've tried it, and no. Honestly C++ gets so many complaints partially because so many people use it. It deserves a lot of it.

I just finished my work on a 2.5 yr rust project that was very low-level. The problems I had with it were that the language and library designs will always be behind the current state of the art in performance. Hardware and systems APIs change quickly, and they can shift the optimal design decisions easily for different workloads. E.g. chiplets on your CPUs can change where you want to put your io_urings, their workers, and any relevant sq_poll threads. Your NIC's DMA/TLS facilities can change your memory pool policies - do you want zero-copy APIs, or is the copy required anyways because of all the CPU-local work you have to do? Do you preallocate and feed giant buffers to register with the io_uring, or do you need to share your memory pool with the rest of the application? Do you use a single mutex for the pool, a hierarchy between thread-local and global? Do you also use a chiplet-local allocator?

What's nice about C++ is that your fight isn't against the language and runtime. They don't care what your situation is. They'll work. You do have to assemble it, and other languages make some assemblies a lot easier to do.

Yes Rust and its libraries are getting better. But so's C++.

On embedded, your fight totally is against language and runtime. Since you cannot gave conformant freestanding C++ without exceptions, rtti and most of STL, "using c++" on embedded always turns into "using gcc" or "using clang" — their mutually compatible, but completely standards non-conformant extensions that make writing for embedded reasonable to even attempt. At that point, is the language still c++?

Meanwhile, both rust and zig will gladly compile your standalone function into standalone binary.

These are legitimate complaints, and I meant for "if you can afford it" to do a lot of lifting in my first comment.