Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Golang generics proposal has been accepted

github.com

Post reply on HN
Print view View original

31–40 of 176 posts

Re: Golang generics proposal has been accepted

#31

Post by zajio1am »

gautamcgoel wrote: post #4

This will probably be downvoted, but I personally never felt a huge need for generics. C doesn't have them and is arguably the most successful language in history. Yes, they are convenient, but they also add a lot of complexity to the language and toolchain. I suspect that this proposal being accepted is largely due to the huge growth of the Go community - I bet the original team (in particular, I'm thinking of Rob P…

> C doesn't have them and is arguably the most successful language in history.

And many C programs just emulate them using crazy macros, that are harder to write and are less typesafe than proper generics.

Re: Golang generics proposal has been accepted

#32

Post by samuell »

Very much excited that this is finally moving forward. Such sweet improvements this will allow for SciPipe and FlowBase when this nears completion [1,2].

It will make it so much easier to enable typed port objects, which can still re-use all the handy functionality for connecting inports/outports, traversing the dataflow graph, etc etc.

[1] https://scipipe.org

[2] ihttps://flowbase.org

Re: Golang generics proposal has been accepted

#34

Post by AnimalMuppet »

maurys wrote: post #2

I wonder if over time, Golang will pick up more type features like Java and other languages have. The general consensus seems to be that powerful type systems are very effective. Personally, the low footprint runtime and concurrency primitives are enough for me and I wouldn't mind the language becoming "less simple" if it helps the ecosystem. Once generics are implemented, I can imagine people requesting for the next…

> Once generics are implemented, I can imagine people requesting for the next "missing" thing.

Perhaps. But there is (currently) no other feature that people have been whining about nearly as much as they have been whining about generics. So I think it's going to be a while before another need is felt to the same degree.

Re: Golang generics proposal has been accepted

#35

Post by Cyph0n »

cies wrote: post #24
gautamcgoel wrote: post #15

Earlier quoted context omitted.

Haha, touche. Your response is fair. My point was only that some people act like any successful language must have generics, which is demonstrably false IMO. I am not opposed to innovation and ergonomics (hence, my support for arbitrary precision ints), but we should carefully weigh the pros and cons of every new proposal, especially if it increases the complexity of the language and toolchain. In my opinion, the ben…

Well, we know now, contrary to what was said about generic-and-Go when Go came out: Go can apparently not do without generics. What I always found hard to swallow is that Go's build in functions sometimes did have generics. Just you as a library/application writer were not allowed to create APIs with generics yourself.

Yep, seemed weird to me how (a form of) generics existed, but was exclusive to the stdlib/language.

If generics were unnecessary, why did the stdlib/language need them? Couldn't they just have lived with, e.g., make_map, make_slice, make_chan, etc?

Re: Golang generics proposal has been accepted

#36

Post by baby »

I really really hope that this does not end up in people abusing generics in Golang code and making Golang code harder to read. The biggest argument of Golang in my opinion is that it is extremely easy to audit and read and understand at the moment.

Re: Golang generics proposal has been accepted

#37

Post by mseepgood »

gautamcgoel wrote: post #4

This will probably be downvoted, but I personally never felt a huge need for generics. C doesn't have them and is arguably the most successful language in history. Yes, they are convenient, but they also add a lot of complexity to the language and toolchain. I suspect that this proposal being accepted is largely due to the huge growth of the Go community - I bet the original team (in particular, I'm thinking of Rob P…

> I'm thinking of Rob Pike

I do not remember him being against generics. He is the one who contacted his former colleague Phil Wadler to help with the theoretical validation of the type parameters proposal. In his talk about the Go 2 draft specifications (back then the proposal was still based on contracts) he was positive that a good design can be found. (*) https://www.youtube.com/watch?v=RIvL2ONhFBI

Re: Golang generics proposal has been accepted

#38

Post by hota_mazi »

gautamcgoel wrote: post #4

This will probably be downvoted, but I personally never felt a huge need for generics. C doesn't have them and is arguably the most successful language in history. Yes, they are convenient, but they also add a lot of complexity to the language and toolchain. I suspect that this proposal being accepted is largely due to the huge growth of the Go community - I bet the original team (in particular, I'm thinking of Rob P…

PHP was also hugely successful, success is not the criterion by which this kind of feature should be decided.

The bottom line is that generics allows the production of safer, more robust, more evolvable, more documented, more performant, code.

Along with static typing, generics are simply a feature that no language created recently should be without.

Re: Golang generics proposal has been accepted

#39

Post by hnlmorg »

kyrra wrote: post #26
hnlmorg wrote: post #19

I really wish they went with angle brackets like everyone else does. I get the argument about not wanting to break existing parsers but this is a significant enough language change to warrant that.

It actually causes ambiguous syntax that isn't easy to solve. See: https://go.googlesource.com/proposal/+/refs/heads/master/des... a, b = w (z) Is this code doing 2 boolean compares, or is it calling a function with "w" with types x and y?

I know it’s not a popular opinion, but one thing I love about Perl and wished more languages adopted was the way how variables and functions could be prefixed by a special character (‘$’ for scalars, ‘%’ for hashes, ‘@‘ for arrays and ‘&’ for functions, though the latter was optional). Perl had a lot of properties that made it look a lot like executable line noise but those prefixes did help with readability in a way that a lot of more readable languages lack.

In the case of Go and the example you’ve given, if ‘W’ were a function then the code should read like this:

   a, b = w()  (z)

Re: Golang generics proposal has been accepted

#40

Post by wtetzner »

SeanLuke wrote: post #16
maurys wrote: post #2

I wonder if over time, Golang will pick up more type features like Java and other languages have. The general consensus seems to be that powerful type systems are very effective. Personally, the low footprint runtime and concurrency primitives are enough for me and I wouldn't mind the language becoming "less simple" if it helps the ecosystem. Once generics are implemented, I can imagine people requesting for the next…

> I wonder if over time, Golang will pick up more type features like Java and other languages have. I hope it doesn't pick them up like Java did. When Java was considering generics, there were two major proposals out there. Sun decided on easily the worst one: type erasure. Now we're stuck with it. When Java was considering closures, there were two major proposals out there that I recall [one being to get rid of Java…

> When Java was considering generics, there were two major proposals out there. Sun decided on easily the worst one: type erasure. Now we're stuck with it.

Though using type erasure may have made the JVM a better target for other languages.

Post reply on HN