Live data from Hacker News

Go 1.27

go.dev

271–277 of 277 posts

Re: Go 1.27

#271

Earlier quoted context omitted.

You can also add support for exhaustive switches on tags.

Just as a linter config though?

No, by leveraging unkeyed struct initializers as the switch case pattern, which the Go compiler does exhaustiveness checking on.

Re: Go 1.27

#272

Earlier 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…

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, 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

#273

Earlier 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.

A friend of mine years ago told me, "given enough time, every programming language will evolve into a LISP[0]."

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

#274
post #258

As 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

I was not sure if people are gonna perceive it as negative... I absolutely love Java... my main point was that Java was already way ahead of the curve...

Re: Go 1.27

#275
post #12

This 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.

For a TL;DR, most relevant comment is: https://github.com/golang/go/issues/76920#issuecomment-53103...

Re: Go 1.27

#276

Earlier 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 ...

I don't know how you're reading the quotes you provide, they seem to directly contradict what you're saying.

Re: Go 1.27

#277

Earlier 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,…

C++ templates and Go generics are very much not the same thing.
Post reply on HN