Earlier quoted context omitted.
You can also add support for exhaustive switches on tags.
Just as a linter config though?
Go 1.27
271–277 of 277 posts
Re: Go 1.27
#272Earlier quoted context omitted.
> Generics were always planned, of course ... This is provably incorrect. The position held for many years by the language authors was[0]: Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do. Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to t…
Considering that Ian was already working on them before 1.0, and never stopped until a solution was found, we know for certain they were planned by at least one person on the Go team. If you are struggling to say that Go people are not a single monolith then sure. Nobody has ever thought people are a single monolith. However, the original announcement makes the intent of the project clear: "Not yet", not "never". The…
> However, the original announcement makes the intent of the project clear: "Not yet", not "never". They were always planned to be accepted into Go.
This is an exceedingly charitable interpretation of the position held by at least one Go language designer (Rob Pike)[0]:
Notice that Robert said C was the starting point, not C++.
I'm not certain but I believe he meant C proper, especially
because Ken was there. But it's also true that, in the end,
we didn't really start from C. We built from scratch,
borrowing only minor things like operators and brace
brackets and a few common keywords.
In the end of course it came out quite different from
either C or C++. More different even than many realize. I
made a list of significant simplifications in Go over C and
C++:
...
- no templates
...
0 - https://commandcenter.blogspot.com/2012/06/less-is-exponenti...Re: Go 1.27
#273Earlier quoted context omitted.
> Generic methods are a huge win for the language. I've been waiting on these kinds of improvements to the type system ... It's funny that you and many others have found the introduction of "generics" in Go to be highly valuable, considering one of the motivations for Go's existence was: Its designers were primarily motivated by their shared dislike of C++[0] One of the language features C++ provides, "templates", wa…
I definitely recall the days when it was not uncommon to see members of the Go community speak out against the idea of generics and other type improvements for allegedly taking away from the language's simplicity. Thankfully that faction lost that argument or otherwise changed their minds, because I have seen first hand how issues with the type system can hold back larger scale libraries.
I laughed at the thought in the moment and now understand the wisdom shared with me.
0 - https://en.wikipedia.org/wiki/Lisp_(programming_language)
Re: Go 1.27
#274As I've always said: every non-functional programming language, as it matures, it's adoption rises in enterprise, eventually starts to become more and more like Java in terms of it's syntax and feature-set.
I know this is supposed to be a negative comment, but I don't think this is a bad thing
Re: Go 1.27
#275This makes me want to find a side project for an excuse to give Go another try (I last used it professionally pre-generics). I do still wish it had discriminated unions (algebraic data types) and some better error handling ergonomics.
Re unions: https://github.com/golang/go/issues/76920 You might want to follow this proposal, if you aren't already. It's the most recent one, and it's supported by quite a few “core members” of the Go Team. I don't think it'll land in 1.28, but I like the fact that it's still a feature that's being actively discussed.
Re: Go 1.27
#276Earlier quoted context omitted.
"May well be added at some point" it said and added they were at some point.
> "May well be added at some point" it said and added they were at some point. That is a very selective quote which does not reflect the context I provided. So I will extract a selective quote which negates the above: We haven't yet found a design that gives value proportionate to the complexity ...
Re: Go 1.27
#277Earlier quoted context omitted.
Considering that Ian was already working on them before 1.0, and never stopped until a solution was found, we know for certain they were planned by at least one person on the Go team. If you are struggling to say that Go people are not a single monolith then sure. Nobody has ever thought people are a single monolith. However, the original announcement makes the intent of the project clear: "Not yet", not "never". The…
Regarding generics (a.k.a. "templates"): > However, the original announcement makes the intent of the project clear: "Not yet", not "never". They were always planned to be accepted into Go. This is an exceedingly charitable interpretation of the position held by at least one Go language designer (Rob Pike)[0]: Notice that Robert said C was the starting point, not C++. I'm not certain but I believe he meant C proper,…