I wasn't planning to turn this into a language flame war, so I'm not going to give details.

Let's just say that the designers of Rust and Go have prioritized very different feature sets when designing their type systems. If you develop in Rust, it's typically because you want to write "fearless code", i.e. attach sophisticated invariants to types to avoid safety issues later in development/coming from client code. If you develop in Go, it's typically because you want "productivity", i.e. reach quickly a point where you code can run and you can start testing it.

As usual, it's a tradeoff. For most tasks, I happen to click better with the former. YMMV

Go doesn't have any closed or sealed types. An "enum" is just a subtype and subtypes can't restrict the range of their values. It's possible to have something like a closed tagged union using an interface with an unexported method and type-switching, but the language won't understand this for e.g. detecting whether a switch without default is exhaustive.

There's also no way to declare a non-nil pointer nor to work cleanly with nested nil-able struct fields.

It lacks expressiveness, which means you actually have to put some thought into your design to avoid butting heads with it. You can't throw up garbage and then keep massaging the types until you can make whatever gobbledygook you came up with fit.

Business/safety critical logic tends to get complicated, and, at least in the case of business software, is more than likely is venturing into unexplored territory, so when you're not very skilled at programming finding the right design can become an insurmountable challenge. A more expressive type system offers a bandaid to work around that.