Live data from Hacker News

What Go Might Be Like With Generics

play.golang.org

11–20 of 49 posts

Re: What Go Might Be Like With Generics

#11

Is the only argument that Go users can come up with against generics is that they don't like the syntax? The pretentious nature of the Go community really puts me off from the language, especially when combined with some of the pretentious designs of Go itself.

No, the argument is that it's unclear how to fit it into the language. Typically, generics are implemented using either code generation (causing code bloat) or type erasure (which requires boxing the type). They're not satisfied with either.

A more accurate version of my comment would refer to "Go users" commenting in this thread.

Re: What Go Might Be Like With Generics

#13
post #7
post #5

is this trying to solve a particular problem or just pandering to the "... but generics!" crowd of trolls? because it doesn't look like it's solving anything, it feels positively ugly, and there's no way we'll every shut those people up no matter how hard we try. there's no generics solution that will do that. thankfully go's authors don't usually favour the internet's opinion on these matters, or we'd be dealing wit…

People who want generics, to solve real problems, in Go are trolls ? Gosh that word has lost all meaning at this point.

. they know who they are.

Re: What Go Might Be Like With Generics

#14

Is the only argument that Go users can come up with against generics is that they don't like the syntax? The pretentious nature of the Go community really puts me off from the language, especially when combined with some of the pretentious designs of Go itself.

No, the argument is that it's unclear how to fit it into the language. Typically, generics are implemented using either code generation (causing code bloat) or type erasure (which requires boxing the type). They're not satisfied with either.

Doesn't Go already do runtime code generation to implement closures?

Re: What Go Might Be Like With Generics

#15

Is the only argument that Go users can come up with against generics is that they don't like the syntax? The pretentious nature of the Go community really puts me off from the language, especially when combined with some of the pretentious designs of Go itself.

Interesting word to apply to anything related to golang. Seems more accurate to suggest that golang (and interest) is an alternative to pretentiousness.

Re: What Go Might Be Like With Generics

#16
post #14

Earlier quoted context omitted.

No, the argument is that it's unclear how to fit it into the language. Typically, generics are implemented using either code generation (causing code bloat) or type erasure (which requires boxing the type). They're not satisfied with either.

Doesn't Go already do runtime code generation to implement closures?

Go does not generate code at runtime.

Re: What Go Might Be Like With Generics

#18
post #9

It is undeniable that generics are a quite demanded feature for golang. We'll see how the language evolves, but I can't see them coming for a "long" time.

I fully support language specialization -- that is kinda the point, it all ends up bits in the end. Rust is a completely different animal than Go yet I think both are awesome! The idea that all languages have to cater to all people is silly. Generics are ALWAYS a trade-off. None is hard for developers, C++ style is terrible for compile (tons of code-gen, macro crap, duplication, de-duplication stages), and Java style…

you're awesome! you totally get the idea, people if the language does not fit your needs move on!!!! I mean seriously making all the fuss about generics even though that Go is being used in major projects (Cloudflare, UK.gov) yet we see more people arguing that is not right.

I'm glad Rob Pike and Co. don't give a rats a about such opinions.

Re: What Go Might Be Like With Generics

#19
I have been writing Go daily at work for about a year and a half. It is now my primary language, and my default choice for any new projects, the way Python used to be. Before that, I come from a background in functional programming (and still find functional programming to be my favorite paradigm).

It seems to me that there are two disjoint sets of people: those who write Go regularly, and those who complain about generics in Go.

Of course, you can interpret this either way you wish!

1) Perhaps those latter people would like Go despite its lack of generics if they only bothered to get familiar with idiomatic Go.

2) Perhaps the lack of generics is precisely what prevents them from writing Go on a daily basis.

But as someone who actually does write Go on a daily basis, and has for a year and a half, I can honestly say that I've only ever missed them a handful of times. And I say this as a functional programmer who is used to being able to call "map" everywhere.

In fact, if I had to prioritize the things that I wish I could change about Go, generics would not be in the top three - not even in the top five[0]. They're just really something that I don't miss anymore.

[0] I could tell you what they are, but that'd be making it too easy - give Go a shot, long enough to realize you really don't need generics as much as you think you do, and then you'll probably have a good idea of the good, bad, and ugly when it comes to Go.

Re: What Go Might Be Like With Generics

#20

Is the only argument that Go users can come up with against generics is that they don't like the syntax? The pretentious nature of the Go community really puts me off from the language, especially when combined with some of the pretentious designs of Go itself.

The pretentious nature of the Go community really puts me off from the language

I have had the exact opposite experience with the Go community. In particular, I've found community hubs like #go-nuts and the mailing list to be professional at worst and friendly at best, and always helpful.

some of the pretentious designs of Go itself.

How can a design be pretentious? Either you favor the design or you don't, but calling it pretentious is simply projecting your own emotions onto the language.

Post reply on HN