> Also not convinced the Go toolchain is better than Rust (other than in terms of compile time). Never claimed this. I compared the Go toolchain with other too

> Also not convinced the Go toolchain is better than Rust (other than in terms of compile time). Never claimed this. I compared the Go toolchain with other toolchains I happened to encounter in enterprise development. > I place a lot of value on leveraging Rust's more extensive type system and abstractions to model the "complex domains". I would also bet that services written in Rust would be more robust than those initially written in Go. In my experience it's not easy to get there in an environment like the one I described in my post, and any non-trivial abstraction carries a relative risk to later become a problem. The problem is that it doesn't matter how "sound" the abstraction is, the product owner will come in and change things in surprising ways. So at that point investing in sophisticated mechanisms becomes a form of premature optimization. That's the reason you can't afford microservices if the business doesn't have a well-defined structure. >Seems to me that Go is more compelling than Rust for enterprise software development because many businesses do a bad job of looking at their development costs over a longer time frame, thus valuing short learning curve over high reliability. For some business, "high reliability" does have less value than a shorter time-to-market, and in enterprise software development providing value to the business is the entirety of your job, not building cool tech. That's why reconciliation procedures exist even now that we have tons of tools to ensure transactional/eventual consistency.