There are all kinds of additional complexity you could add to the type system to get additional safety. Unique pointers and linear typing are a few options, this is the route that Rust is going. But with complex type systems comes a lot of pain and work arounds to get around the types when you need to. Is the benefit of the additional safety worth the complexity?
For some features (your examples of linear types are good ones) the cost-benefit analysis is not clear.
For other features (explicit nullability, sum types, etc) the cost-benefit is very clearly in favor of having those features, at least according to all PL researchers and most users who have experience with languages that have these features.
> For other features (explicit nullability, sum types, etc) the cost-benefit is very clearly in favor of having those features, at least according to all PL researchers and most users who have experience with languages that have these features.
In a vacuum, sure. But sum types don't interact in obvious ways with Go interfaces.
And FYI, I enjoy both Haskell and Go. Each have their own strengths (and weaknesses). Haskell's expressiveness and safety are a pure joy to work with. But the simplicity in the language design of Go make working with the language very productive. (I very rarely find myself in a situation in Go in which I have to think about "how do I express this idea using Go". Unlike Python and Haskell, which are huge languages.)
The cost-benefit analysis of a language feature MUST be performed in the context of a language and its stated goals.
