Tbh there is a huge industry aroumd C++ robotics code so I can see why.
At my robotics company (where I lost so many hours compiling overly-templated code in C++), I was able to convince my boss to start a new small product in Rust (was an internal simulation tool) and it convinced him to let me work on another new product a few month later, also in Rust, on a much bigger scale. He had only ever worked in C++ before, and I guess he doesn't mind to loose hours compiling and fixing memory leaks. But regardless, it worked and now I can work (a bit) in Rust.
This implies that Rust doesn't have any problems, which is...crazy.
In addition to the problematic community, just rearchitecting your code to fit around the borrow checker can be a massive amount of work, which already makes it infeasible for use in some places where the primary work is not on greenfield projects but on legacy code.
> Unfortunately theres an old guard that refuses to let up and invest in rust.
...and this is just emotionally manipulative, in addition to incredibly dishonest about the problems that Rust actually has.
But TBH, in a Rust world, it’s worth revisiting the assumptions behind the ROS node architecture, since Rust is so strong at scaling to large monolithic applications (due to the strict hierarchical code patterns it encourages).
A transitional Rust approach, that doesn't try to reimplement everything from scratch, could do something like a strangler pattern: Take each ROS node, run them separately in “jails” with a Rust API around each one, then implement the plumbing/management logic in pure Rust.