1. 22
  1. 6

    Good lord:

    if !userHasPermission() {
        // If we return ErrPermission directly, callers might come
        // to depend on the exact error value, writing code like this:
        //
        //     if err := pkg.DoSomething(); err == pkg.ErrPermission { … }
        //
        // This will cause problems if we want to add additional
        // context to the error in the future. To avoid this, we
        // return an error wrapping the sentinel so that users must
        // always unwrap it:
        //
        //     if err := pkg.DoSomething(); errors.Is(err, pkg.ErrPermission) { ... }
        return fmt.Errorf("%w", ErrPermission)
    }
    

    If the path you followed has led you to this, of what use was the path?

    1. 3

      This seems honestly a reasonable way to avoid people accidentally using the API in a way that will prevent its smooth evolution. Am I missing something?

    2. 11

      It’s kinda like they rediscover language design problems as they go. Hopefully they will manage to also rediscover the well-known solutions, instead of NIHing their own, too.

      1. 5

        I do get a lot of Java 1.4 flashbacks when working in Go. I wonder how long until those become Java 5.0 flashbacks.

        1. 2

          I do get a lot of Java 1.4 flashbacks when working in Go.

          That’s interesting, can you give some examples?

          1. 5

            Just some little things like iterating over collections, codegen, and marshalling i/o. I’m coming back to static typing after many years in Ruby so it’s not exactly Go’s fault. Though it’s a bit surprising when a Go binary has a similar file size to a WAR file from back in the day!

            Overall I think Go is still way ahead of Java 1.4, both as a language and an ecosystem. The stdlib and dependency management are great. I’m very happy to never have to maintain a pile of ant+ivy config again. I know error management is a pain for many in Go but it was a pain back in the day for Java too. So many wars over checked vs unchecked exceptions. The only thing you can be sure of as a language designer is that you can’t please everyone.

            1. 1

              In Java 1.4 you had to use an explicit index counter to iterate. Go started out with range-based iteration. So not sure what you meant here.

              The marshalling does feel similar. I haven’t seen better approaches though. Do you know of any? [I haven’t used Ruby so am not familiar with how it handles marshalling.]

        2. 8

          I think that characterization is somewhat unfair. Given the backgrounds of Go’s designers, they were probably aware of most language design problems. They just opted to make Go simple (for some definition of simple).

          What I find interesting to see is how they will manage to add generics to the language (since apparently they want to add generics now), without breaking backwards compatibility and while simultaneously avoiding making it a bolted-on thing (such as Java generics).

          1. 2

            I think that characterization is somewhat unfair. Given the backgrounds of Go’s designers, they were probably aware of most language design problems. They just opted to make Go simple (for some definition of simple).

            I wonder where this allocation of undeserved credit comes from … why not judge people by their actions, instead of appealing to authority? I think it’s pretty obvious that they are blissfully unaware and uninterested in anything that they didn’t invent themselves at Bell Labs 30 years ago.

            What I find interesting to see is how they will manage to add generics to the language (since apparently they want to add generics now), without breaking backwards compatibility and while simultaneously avoiding making it a bolted-on thing (such as Java generics).

            They won’t? :-)

            1. 18

              I think it’s pretty obvious that they are blissfully unaware and uninterested in anything that they didn’t invent themselves at Bell Labs 30 years ago.

              Go language design proposals mention feature-relevant PLT and explain in some detail why various approaches or solutions are or are not relevant. This analysis isn’t hidden from view. Consequently it’s hard to take this kind of grumpy sniping as anything other than blissfully uninformed sour grapes.

              1. 2

                I’ve seen public discussions regarding Generics, yes, but not about other topics. Still, it seems to me that most discussions regarding that revolve around “well, we screwed up during language design. How do we fix it now without breaking backwards compability?”

                But I’m still curious, anyway. Can you point me to a text describing why they decided to standardize on such lackluster error handling approach? Or even why they decided to not implement enums as a language construct and went with iota instead.

                1. 4

                  Or even why they decided to not implement enums as a language construct and went with iota instead.

                  You might not agree with it, but it’s been in the FAQ for ages: https://golang.org/doc/faq#variant_types

                  If you search gonuts, I recall there being more discussion about it.

                  My take is that they don’t assign a lot of value to exhaustiveness checks, or at least, value other things over it.

                  1. 1

                    I meant enums as variant types (like in Rust), but as grouped constants (like in C#).

                    Thanks for the FAQ and gonuts suggestions, though. I’ll see what I can find there.

              2. 3

                I wonder where this allocation of undeserved credit comes from … why not judge people by their actions, instead of appealing to authority?

                Previous languages that they have been involved in designing – Alef, for example– have had generics and exceptions.

                1. 1

                  Interestingly, genericity was already gone three years later in Limbo. So I guess parameterized ADTs were indeed not seen as a redeeming feature of Alef.

          2. 5

            This is a fine article, but I thought this one was more straight to the point.