Uh oh. So immediately you do understand that you have taken on the risk of potentially being unable to find any good(or bad) Rust engineers in the future, correct? Also they won’t be cheap as there won’t be many of them.
A smarter, business-friendly, future-proof approach would be to have done that in Java. Future you will want you to have done that in Java, but if you’re trying to retain good engineers maybe I get the Rust thing.
I was a fan of Java for a very long time. It was my language of choice from early 2000s to mid 2010s. It does _amazing_ things with keeping memory management out of mind (while still giving you the the "backdoors" to make things work well if you need a non-gc approach), but thread safety continues to be a glaring hole.
From a former Java super-fan, I honestly think the future is Go + Rust.
FWIW we also evaluated Go as a shared language, but there were risks around integrating our Go shared library with apps that may include some pre-existing Go code.