While I agree with you that such complexity is expensive to manage, I think it primarily depends on the expertise of your team. If you can foresee the need for

While I agree with you that such complexity is expensive to manage, I think it primarily depends on the expertise of your team. If you can foresee the need for Rust, say, and your team knows how to manage its risks, and it is financially viable to maintain so many stacks, I think it’s fine. But if the team just wants to put a badge on their chest for using Rust, that’s a different story. I’ve been always striving to reduce the complexity and pick only one framework. Sometimes it’s hard and such decisions must be made. On a larger project I integrated and developed Go, Rust, and Java services, tightly knit to their context bounds. It was alright and seemed to make sense but the strain was immense. People tend to underappreciate how much time it costs to do the context switch in your head when you change across different stacks, and how much lost opportunity it incurs for not spending that time to dice deeper in only one tech stack.