This post demonstrates the fundamental flaw with RIIR arguments: it assumes that Rust is not only the best language now but will always be the best language. Getting halfway through a rewrite from C to Rust only to realize that Rust is no longer popular and there's a new kid in town would be pretty awkward.
I mean, that's the case for literally every technology that improves on what comes before. If you follow that logic you can never rewrite anything... which, granted, might be a decent idea, but not one that has anything to do with Rust.
On the other hand, "a new kid in town" is not a good reason to declare a rewrite a failure. Did it make your life better? Did it reduce bugs with a reasonable amount of effort? Maybe it was a good decision after all, given what you knew and what was available at the time.
Meanwhile, delaying a decision indefinitely just in case better options appear later is probably a road to death. Again, Rust doesn't come into the question all that strongly.
To me Rust's main advancement isn't technical. It's that software development is first and foremost an ongoing social activity rather than the finite output of a single mind. Rewriting something in Rust shouldn't be about fixing potential bugs but about making the code safely accessible to a wider range of coders than the original (C) codebase was. Rust itself evolved mostly as a collective effort and nurtured a strong and mostly wholesome community and culture which IMO is what gives it staying power.
In practice, there are so many things to write to make even a simple language useful that the transition time can be fairly long: libraries (especially non-trivial ones like date&time), tooling, best practices...
There's a lot of overhead that can't really be reduced.
> Getting halfway through a rewrite from C to Rust only to realize that Rust is no longer popular and there's a new kid in town would be pretty awkward.
This is nothing new ...
See: the mid-to-late 1990s and Perl, Python, Tcl, etc.
The only way to predict the furture is to create it.
And that his like the point of Rust? It put in the spotlight this stuff.
You could see the seeds of Rust from years ago, but having a nice language as the start is just... the start.
Rust do that AND all the other things: tooling and docs and..
So, the thing that will replace Rust will need that, and is likely you will not see any proper* contender in the next 5 years, maybe even more...
*ie: One where it worth to rewrite the codebase. You will see several experiments, maybe a few very good, but consider this: To rewrite from C/C++/.. to Rust have a lot of leverage: C performance, superior tooling, superior error messages, superior docs. Your Rust replacement should be BETTER than that.
