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.
A bit of cart-horse-y reasoning…. An expressive type system helps me to model the nuances that are actually present in the business logic. If I simplify or restructure my model more than real life allows for I would say that causes much more trouble than actually modeling what’s happening on the ground.
Yes, when I’m behind my desk I always find ways to make the business logic better and simpler and more fitting. But those damn humans never follow my rules.
Strictly speaking, that is true. Even the worst code ever written had some thought put into it. But the "actually put some thought" was meant to imply more than putting down the first characters that spew out; to consider the design more holistically and carefully.
But you are right to not take anything that software says seriously. Seriousness is for interactions with humans.
