4 ms·

Hoare only gave this talk in 2009, whereas Go development started in 2007. Did Hoare express this opinion publicly (or privately, to the Go developers) before t

Hoare only gave this talk in 2009, whereas Go development started in 2007. Did Hoare express this opinion publicly (or privately, to the Go developers) before then? I can't easily find any indication that he did. I can imagine goto makes region analysis hellishly more difficult, and region analysis is what gives Rust the ability to statically reason about reference lifetimes, which makes it practical to remove null references from the language. So on the Rust view, goto is even more antithetical to safe code than on Dijkstra!

azth 13y ago
Indeed. Plus, I have never read a convincing response from the Go authors as to why they included null in the type system.
- burntsushi 13y ago
  It's been hashed out over and over again on the mailing list. Their stance boils down to language design cohesion. In particular, avoiding null in your type system while preserving orthogonality in your language design would require a completely different language than the on that Go embodies. (This is in stark contrast with say, the Haskell community, which will add any new feature produced by original research.) If you dig through the mailing list posts, avoiding null in the type system can be difficult to reconcile with "zero values", which each type has. More subtlety, avoiding null in your type system might require adding support for sum types, which conflicts in weird ways with Go's interfaces. I think a lot of people tend to assume that null should always be eliminated from type systems because doing so can be done for free. But I disagree that it can be done for free, and my evidence is in the aforementioned mailing list posts. The other reason why I suspect we'll never see the elimination of null in Go's type system is that it just isn't that big of a source of bugs. Anecdotally, I very rarely see my program crash because of a nil pointer error, even while doing active development. I could hypothesize as to why this is, but I'll just leave you with this thought: the type system isn't the only thing that can reduce the occurrence of certain classes of bugs.
  - pcwalton 13y ago
    I never found the conflicts with interfaces issue that Russ Cox raised to be convincing. Just require that the sum type be destructured before calling methods on it. This is what Rust and Scala, both of which have something akin to Go's interfaces, do. The bigger issue is that having a zero value for every type does indeed conflict with not having null pointers. I feel that pervasive zero values box the language design in so heavily that the convenience they add doesn't pull the weight, but Go's designers evidently disagree. In any case, Go's language semantics are so based around zero values (e.g. indexing a nil map returns zero values instead of panicking for some reason) that they can't be removed without massive changes to the entire semantics.
    - burntsushi 13y ago
      From the Go FAQ: > We considered adding variant types to Go, but after discussion decided to > leave them out because they overlap in confusing ways with interfaces. What > would happen if the elements of a variant type were themselves interfaces? It's not that there isn't a way to implement sum types in Go, it's that they aren't happy with how they interact with interface types. (That's how I interpret it, anyway.) I'm sure you and I can conceive of reasonable ways for them to coexist, but simply coexisting isn't enough for the Go devs. > The bigger issue is that having a zero value for every type does indeed conflict with not having null pointers. I agree that it is indeed the bigger issue. Personally, I make use of the "zero value" feature a lot and very infrequently run into null pointer errors while programming Go. So that particular trade off is clear for me. (I certainly miss sum types, but there is a bit of overlap between what one could accomplish with sum types and what one can accomplish with structural subtyping. Particularly if you're willing to cheat a little. This alleviates the absence of sum types to some extent. Enough for me to enjoy using Go, anyway.) OT: I love the work you are doing on Rust. :-)
      - pcwalton 13y ago
        That FAQ entry and associated mailing list posts was what I was referring to as unconvincing. I don't see how sum types and interfaces are in conflict: just require destructuring before calling interface methods, as Scala does.

azth 13y ago

Indeed. Plus, I have never read a convincing response from the Go authors as to why they included null in the type system.

burntsushi 13y ago
It's been hashed out over and over again on the mailing list. Their stance boils down to language design cohesion. In particular, avoiding null in your type system while preserving orthogonality in your language design would require a completely different language than the on that Go embodies. (This is in stark contrast with say, the Haskell community, which will add any new feature produced by original research.) If you dig through the mailing list posts, avoiding null in the type system can be difficult to reconcile with "zero values", which each type has. More subtlety, avoiding null in your type system might require adding support for sum types, which conflicts in weird ways with Go's interfaces. I think a lot of people tend to assume that null should always be eliminated from type systems because doing so can be done for free. But I disagree that it can be done for free, and my evidence is in the aforementioned mailing list posts. The other reason why I suspect we'll never see the elimination of null in Go's type system is that it just isn't that big of a source of bugs. Anecdotally, I very rarely see my program crash because of a nil pointer error, even while doing active development. I could hypothesize as to why this is, but I'll just leave you with this thought: the type system isn't the only thing that can reduce the occurrence of certain classes of bugs.
- pcwalton 13y ago
  I never found the conflicts with interfaces issue that Russ Cox raised to be convincing. Just require that the sum type be destructured before calling methods on it. This is what Rust and Scala, both of which have something akin to Go's interfaces, do. The bigger issue is that having a zero value for every type does indeed conflict with not having null pointers. I feel that pervasive zero values box the language design in so heavily that the convenience they add doesn't pull the weight, but Go's designers evidently disagree. In any case, Go's language semantics are so based around zero values (e.g. indexing a nil map returns zero values instead of panicking for some reason) that they can't be removed without massive changes to the entire semantics.
  - burntsushi 13y ago
    From the Go FAQ: > We considered adding variant types to Go, but after discussion decided to > leave them out because they overlap in confusing ways with interfaces. What > would happen if the elements of a variant type were themselves interfaces? It's not that there isn't a way to implement sum types in Go, it's that they aren't happy with how they interact with interface types. (That's how I interpret it, anyway.) I'm sure you and I can conceive of reasonable ways for them to coexist, but simply coexisting isn't enough for the Go devs. > The bigger issue is that having a zero value for every type does indeed conflict with not having null pointers. I agree that it is indeed the bigger issue. Personally, I make use of the "zero value" feature a lot and very infrequently run into null pointer errors while programming Go. So that particular trade off is clear for me. (I certainly miss sum types, but there is a bit of overlap between what one could accomplish with sum types and what one can accomplish with structural subtyping. Particularly if you're willing to cheat a little. This alleviates the absence of sum types to some extent. Enough for me to enjoy using Go, anyway.) OT: I love the work you are doing on Rust. :-)
    - pcwalton 13y ago
      That FAQ entry and associated mailing list posts was what I was referring to as unconvincing. I don't see how sum types and interfaces are in conflict: just require destructuring before calling interface methods, as Scala does.