From my point of view, the significant tradeoffs made in the design of go make it better suited toward software that has to change a lot: e.g., things closer to

From my point of view, the significant tradeoffs made in the design of go make it better suited toward software that has to change a lot: e.g., things closer to customer-facing that are constantly being iterated on. Rust is more appropriate for areas where the problem boundaries are relatively fixed and slow-moving: libraries, backend services, and infrastructure. By better allowing you to model your program domain, Rust actually lets you finish projects that are feature complete. I have multiple Rust projects in production for years that have needed at most one or two bugfix releases after their initial rollout on top of a half a dozen feature updates. For a very slight additional startup cost in doing that modeling, I’ve gotten massive dividends back in the volume of maintenance programming that hasn’t needed to be done. But if your problem domain changes frequently enough that the model needs to be changed all the time, that extra inflexibility isn’t worth it. On the other hand, I don’t know much go software that isn’t beset by the same number of bugs as every other modern language.