3 ms·
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, et
by Peaker 14y ago
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.
- burntsushi 14y ago> 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.