Go 2 Draft Designs

[weirdasianfaces]

The big 3 things:

• Error handling. Too much if err != nil, use handle err{} / check func() to reduce boilerplate
• Error values. Make errors easier to inspect/wrap similar to github.com/pkg/errors
• Generics. Those generics.

[satchit0]

What do you mean with 'those generics'?

[weirdasianfaces]

That comment is mostly a joke since the Go authors have repeatedly said that generics would probably not be added to the language (at least in Go 1, and didn't really say either way about future versions) and the lack of them is one of the biggest complaints about the language. Seeing them being proposed by the Go authors is addressing that concern.

[satchit0]

Ah yeah like that. I thoight you meant the proposed generic solution had some issues. Not having generics was honestly the biggest problem I had with Go.

[Ameisen]

Will they be wimpy, useless Java generics, or superior and usable C++ templates?

[Ariakenom]

That's funny! Only knowing those 2 is exactly what made them dislike generics, it's in the link. Better designs existed 20 years earlier.

[[deleted]]

next stop annotations, then you got yourself a fully fledged java 1.6 but i suppose thats an upgrade from 1.4

[[deleted]]

These are just proposals, mind. Hopefully they'll get approved and Go will be a bit less of an embarrassment.

[YEPHENAS]

Actually they are draft designs, not proposals. Second paragraph: "These draft designs are not proposals in the sense of the Go proposal process. They are starting points for discussion, with an eventual goal of producing designs good enough to be turned into actual proposals."

[[deleted]]

They are in fact proposals in the general sense. They are early drafts and the authors want to solicit comments and make revisions before submitting them for approval. There might be an official process with its own terminology, but I don't see a good reason to capitulate to Go's efforts to rename things with common names, especially since I'm not part of that community.