1. 17
  1.  

  2. 3

    I was able to quickly share state via pointers without worrying about safety, which was quite useful.

    Is this true? I was under the impression that you had to be careful about these things in Go.

    I think the point about lack of enums is great. In languages I tend to use generics often go hand-in-hand with enums (variants), but Go could have had enums without variants that would have added a nice layer of type safety to the language.

    I think the point about visibility is good too. It’s just weird, IMO, that visibility is based on the capitalisation of something. Personally, I think the MLs have it quite right with interface files. It makes it really easy to get an overview of the API a module provides.

    All-in-all, I enjoyed this read. Not really coming down on one side or the other but just talking in rather neutral terms about what the languages provide.

    1. 1

      The point about the lack of “enums” is incorrect. What Rust calls enums are what Haskell calls “sum types”. They’re not a built-in in Go but can be easily implemented this way:

      http://www.jerf.org/iri/post/2917

      The philosophy of Go is to keep the language simple by avoiding adding new language features when it isn’t necessary. In this case the resulting Go code is a little verbose but it’s easily understood.

      1. 7

        People need to stop saying that enums/sum types/unions/adts can be implemented in Go. @jerf proposes a very satisfying alternative (that I’ve used myself on several occasions). It achieves a lot of the same things, but it is subtly different. For example, the number of possible variants is limited by Go’s visibility rules rather than an explicit language construct. If Go really had support for sum types, then they would be used to handle errors.

        In some languages (like Rust and Haskell), sum types are deeply connected to pattern matching, which is immensely satisfying to use.

        1. 5

          What Rust calls enums are what Haskell calls “sum types”. They’re not a built-in in Go but can be easily implemented this way:

          I can’t speak for Rust, but @jerf definitely does not implement Haskell sum types. Most is missing, most meaningfully to me, is the lack exhaustiveness. And the boilerplate is a bit ridiculous.