> I personally can’t wait to see what next development will never have been “against the Go philosophy” and definitely not something that gophers argued was perfect the way it was any time misguided malcontents and rabble-rousers wrongly tried to suggest the language wasn’t perfect the way it was.

I really hope it is more ergonomic error handling. Or maybe sum types/discriminated unions.

▲ stouset 6 hours ago | parent | next [-]

Those are fine the way they are. I don’t want the language getting more complicated. Rob Pike has said they’ll never happen. Suggestions like this are extremely against the Go way of doing things. Actually the verbosity is a good thing. It’s explicit.

▲ Joker_vD 5 hours ago | parent | prev [-]

> I really hope it is more ergonomic error handling.

They've publicly said no more language changes specifically for better error handling are coming, it will at most be the library-level improvements.

▲ stouset 5 hours ago | parent [-]

So this would be in line, then, with all of the other features they’ve publicly said aren’t coming and aren’t necessary but then do anyway after retconning their original stance?

▲ Joker_vD 4 hours ago | parent [-]

Could esteemed commenters please read the words the Go language team actually wrote?

    > Or, we could decide that parameterized methods do not, in fact, implement
      interfaces, but then it's much less clear why we need methods at all. If
      we disregard interfaces, any parameterized method can be implemented as a
      parameterized function.
    
    > So while parameterized methods seem clearly useful at first glance, we
      would have to decide what they mean and how to implement that.

Well, they have finally decided what parameterized methods actually mean, and they see how to implement that, and it all seems clearly useful. So...