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

Why Generics?

blog.golang.org

Post reply on HN
Print view View original

111–120 of 261 posts

Re: Why Generics?

#111

Post by rad_gruchalski »

freetobesmart wrote: post #27
rad_gruchalski wrote: post #10

Earlier quoted context omitted.

Every project I’ve written so far in golang could benefit from generics.

but what is the benefit? How does your code change. Generics are a tail abstraction. Its the last abstraction that you are able to make to your code to reduce boilerplate. This usually means that is the least useful and in generics specific case the boiler place it reduces is minimal. Its lack of impact is why I dont really care about the subject. Adding or removing generics to a project matters little. So why bother…

My experience from scala is that the use of generics is not an afterthought, not a boilerplate abstraction. They’re come in handy naturally when one knows how to use them, and it is not rocket science.

The real benefit of generics. They enable composability. The complete scala collections library is the best example of that. The benefit is non-obvious on a single function level, a complete program is another story.

It’s, of course, possible to to achieve something like this with golang and interface{}. I don’t mind working with it, all the type switches and what not make feel like a proper tinkerer! What is actually happening:, I’m wasting my time, the compiler already knows all the types. It can figure things out for me. Of course, a sound type system is then needed.

The types switches are error prone, it’s like working with java.lang.Object everywhere. And if I can avoid all these “GetX” functions, where X is “String”, “Int”, “Int32”, “Int64” and so on, even better. Just look at viper, it would be so clean and lightweight with generics.

Re: Why Generics?

#112

Post by mixedCase »

Vendan wrote: post #95
mikeash wrote: post #82

Earlier quoted context omitted.

This is the Blub Paradox. http://wiki.c2.com/?BlubParadox

What is it when you know about the power of features of the "higher level" languages, like generics, but still chose the "blub language" because of other reasons, like ease of hiring devs?

"Worse is better"

Re: Why Generics?

#113

Post by icedchai »

mrkeen wrote: post #62
olooney wrote: post #23

Earlier quoted context omitted.

What is HKT?

I'll give the 'why' rather than the 'what'. In most mainstream languages you take a List and substitute for List without changing the implementation of List. But there's another substitution you could have made, which is L . HKT allows you to parametrise L over Int, in the same way you were able to parametrise List over Int.

Thanks for the practical, plain English definition. As someone many years out of school, it is appreciated.

Re: Why Generics?

#114

Post by shaded-enmity »

iainmerrick wrote: post #74

Maybe this is unfair, but it’d be great if the Go devs could just say “generics will work similarly to [C# / Java / Swift / D / whatever], except that we’ll address [problems] with [adjustments]”. Rather than going through this whole rigmarole of resisting adding generics too early because all existing implementations are bad, then slowly reinventing the wheel from scratch, then finally ending up with something prett…

What is your point? Serious question.

If you tell me, for example, that Go generics are going to be like C# generics, then I have to be familiar with the full semantics of C# generics. Essentially you tell me that in order to understand X I have to understand Y first, that's not good. Consumers of your language are not, for the MOST part, PLT nerds.

Re: Why Generics?

#115

Post by iainmerrick »

grumdan wrote: post #104
iainmerrick wrote: post #74

Maybe this is unfair, but it’d be great if the Go devs could just say “generics will work similarly to [C# / Java / Swift / D / whatever], except that we’ll address [problems] with [adjustments]”. Rather than going through this whole rigmarole of resisting adding generics too early because all existing implementations are bad, then slowly reinventing the wheel from scratch, then finally ending up with something prett…

> because all existing implementations are bad I'm also not sure why in OOP-land, generics are this crazy experimental weird feature, when in functional languages, people figured out how to implement parametric polymorphism (the original term for generics) in quite reasonable ways. I get that subtyping adds some complexity, but overall I don't understand why such a basic way to build abstractions is so controversial…

Just to be clear, I don’t think all existing implementations are bad, that was my (possibly unfair) caricature of the Go devs’ position.

Re: Why Generics?

#116

Post by weberc2 »

iainmerrick wrote: post #96
weberc2 wrote: post #85

Earlier quoted context omitted.

It seems like you’re objecting to the messaging (not referencing an existing language, which doesn’t work for people not familiar with the implementation of that language) and also that, at its inception, Go didn’t pick (randomly?) a language off of which to model its generic implementation. Am I misreading?

Well, there doesn’t seem to be a lot of discussion of alternatives at all, so I can’t really see what design and implementation decisions are actually being made. Most likely I’m just looking in the wrong place, and those discussions are taking place elsewhere. I guess my complaint is that this talk, like all the other updates on their progress on generics, implies that Go generics exist in a vacuum, whereas in reali…

As jerf mentioned, there has been lots of talk; every single time the question of generics is raised here, /r/programming, or any Go-specific forum, it's addressed.

With respect to interfaces vs contracts; interfaces are about runtime polymorphism while contracts are about compile time polymorphism. This is an important difference when you consider []interface{Foo()} vs Slice(contract{Foo()})--an instance of the former can contain elements of varying concrete types while an instance of the latter can only contain elements of the same type. The other important detail is that interfaces only abstract over a single type while contracts support multiple type parameters (a single contract could specify a visitor type and a vistee type, for example).

Re: Why Generics?

#117

Post by aldanor »

aczerepinski wrote: post #98

Mixed feelings about this. One of my favorite things about Go is that it's a small and relatively simple language. It's a "fast enough" language without the steep learning curve of Rust. Too many features that make sense individually could change the calculus to "might as well use Rust".

I'm not so sure about the "steep learning curve of Rust" stereotype anymore. If you are comfortable with low-level programming languages in general, in a few days you can get yourself started fairly quickly with Rust to the point where you will still battle with compiler re: borrowing and related things, but will be able to write functional code. Coming from pure Python/JS will be tough, but it will be the same with any other low-level language.

Re: Why Generics?

#118

Post by dllthomas »

AceJohnny2 wrote: post #108
chc wrote: post #81

Earlier quoted context omitted.

I think you're talking about the Blub Paradox, by the guy who started this site.

Huh. Yeah, that's exactly it. Funny coincidence :)

Your presentation seems less directional than the original Blub article, FWIW.

Re: Why Generics?

#119

Post by enneff »

weberc2 wrote: post #94
jknoepfler wrote: post #88

The decision to overload parentheses to express generic type is the only part of this spec I find nauseating. It doesn't scan well, and doesn't have a precedent in any major generic implementation I'm aware of. <, [, @-annotation... I don't care. Just don't mush it into the function declaration with the same syntax that encloses parameter.

Agreed, specifically it creates ambiguities in parsing (for computers but worse: for humans). Given Foo(x), you can’t tell if it’s a function call or a generic type without knowing what x refers to. You need context from afar to disambiguate.

You can tell if it’s a function call or a generic type based on where it is used; the local context. Function calls are either statements or expressions. Types appear in declarations.

Re: Why Generics?

#120

Post by nevir »

Nevermindmine wrote: post #109
Vendan wrote: post #47

Earlier quoted context omitted.

Chiming in as a fervent Go dev that's also a huge fan of generics: Generics are awesome, but always seem to add a ton of complexity. Everyone starts with just "oh, `func Reverse(slice []T)` is so obvious" kind of thing, but that's like saying `fmt.Println("Hello World")` is simple. It's simple cause you are doing a simple thing. That said, I do want generics to come to Go, just... with an emphasis on what Go is, not…

> Generics are awesome, but always seem to add a ton of complexity The team I work in use generics all the time and I'm not sure what complexity you are referring to. Care to elaborate? Is it some edge cases or are you talking about from a compiler perspective or something else? To me, not having generics is like saying let's skip handling bools and just store them in strings as "true" or "false". It's such a weird t…

I think TypeScript is a good example of one extreme. You've got conditional types, literal types, type mapping, and a bunch of other very advanced parameterized types.

(I also think it makes sense for TypeScript given JavaScript idioms; it mainly falls over when the caller has to interpret some very complicated error messages, however)

Post reply on HN