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.
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.