4 ms·
Well I think part of the problem is that most of Go's target audience come from languages where nil/null are used to be meaningful. They recognize it to be "wr
by throwit1979 13y ago
Well I think part of the problem is that most of Go's target audience come from languages where nil/null are used to be meaningful. They recognize it to be "wrong", but the languages in use (e.g. Java) force them into situations where, for example, returning null to mean "this entity wasn't found" is substantially more productive than catching and processing EntityNotFoundException.
I think the Go designers wanted the language to be approachable for people who habitually use null to indicate meaningful state. Multiple return values offer a way out, while still allowing newbies the option to abuse nil. (although, sum types would be nicer)
I think on balance, getting people from the 1970s to the 1980s who otherwise would not have gone there is a positive thing. Even if it's not the ideal thing.
It's not out of the question that Go will make your suggested fixes once it acquires enough mindshare.
- jerf 13y agoGo look at C#, or any other language that has this concept. The point is not that there would be no nil, anywhere, ever, the point is that you would have to ask for it, and by default, you get a type that can't contain nil. C# even proves it can be profitably bolted on after the fact (contra pcwalton)... because that's how unobtrusive this change is. It's not like this is a complicated idea, unlike the other suggestions.
- pcwalton 13y agoRemoving nil from Go is not possible without breaking backwards compatibility. The Go core team considers nil a feature anyhow.