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

141–150 of 261 posts

Re: Why Generics?

#141

Post by justinhj »

gizmo686 wrote: post #137
grumdan wrote: post #104

Earlier quoted context omitted.

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

Inheritance makes generics difficult. For instance, if A If you are just reading the array, you would want Array[A] This problem doesn't come up in ML style languages because they do not make use of inheritence.

It comes up in Scala. The solution is to have notation to specify the variance of types.

Re: Why Generics?

#142

Post by owaislone »

fabiensanglard wrote: post #60

I hope this doesn't happen. I love golang because it is simple and easy to read. Both will go away when generic programmer start to write unreadable meta-programming class which "you don't need to understand, just use them". I admire golang devs for being opinionated and stand up for the core lines of their language so far. I see generic as renouncing these principles.

May be you could share feedback with us and the designers about which parts you think will be hard to understand? This is a valid concern but only way to address this is to specify and share as feedback to the proposal.

Re: Why Generics?

#143

Post by ben509 »

hinkley wrote: post #50
haolez wrote: post #2

Personally, I prefer the current interfaces-based solution to generics. It's a little verbose, but keeps the language simple. However, I think that the people we should be listening most are the ones developing huge projects in Go, like Kubernetes. Would having generics with this new contracts thing make it easier to develop and maintain e.g. Kubernetes? I'm truly curious.

I'm a little surprised the word 'mixin' appears nowhere in that article. Josh Bloch argued against the interface solution in Java (and in particular, read-only versus read-write interfaces), claiming there would be too many interfaces and it would confuse users, and that didn't sit right with me. To me it's his second-biggest sin against Java, and it's tied to the first. The only truly unforgiveable one is Unsupporte…

> The only truly unforgiveable one is UnsupportedOperationException. The guy who wrote the collections API for Java didn't know the first thing about the Liskov Substitution Principle, and gave the world an implementation that violates it...

The implementation perfectly follows it because the LSP simply requires identical behavior, and the contract clearly states it may[1] throw an exception. All the implementations "may" throw an exception. Sorry, but they correctly lawyered the LSP.

> I came up with around 20% more than the selected design.

But `add` can throw 5 different exceptions depending on restrictions your implementation wants to place on a given collection, does it allow for all that? In terms of making an interface that was small and reusable by many projects, runtime exceptions are a pretty good compromise for a standard library.

[1]: https://docs.oracle.com/javase/7/docs/api/java/util/Collecti...

Re: Why Generics?

#144

Post by darkr »

RivieraKid wrote: post #107
grumdan wrote: post #104

Earlier quoted context omitted.

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

> I'm also not sure why in OOP-land, generics are this crazy experimental weird feature It's not, it's an essential, basic feature.

I’d say in Java they’re still not quite there, being implemented via compile-time type erasure and runtime type-assertions.

Re: Why Generics?

#145

Post by filleduchaos »

baby wrote: post #132
grumdan wrote: post #104

Earlier quoted context omitted.

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

It makes code unreadable. void lol >, E>()

Pretty much all syntax is unreadable if you don't know the lingo. For example, try presenting the ubiquitous

    for (int i = 0; i
to ten random people without prior programming experience and see how many of them can correctly tell you what all that means. Similarly,

    { a, b in a > b }
is probably not very clear to people who don't write Swift and perfectly lovely closure syntax to people who do.

There's language syntax that's actually unreadable, for instance due to using names that obscure or otherwise don't clearly express what a construct is/does or using the same operator/keyword for too many different context-dependent purposes. I don't quite think the sheer presence of angle brackets makes code unreadable, any more than the sheer presence of curly braces or parentheses do.

Re: Why Generics?

#146

Post by notus »

RivieraKid wrote: post #107
grumdan wrote: post #104

Earlier quoted context omitted.

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

> I'm also not sure why in OOP-land, generics are this crazy experimental weird feature It's not, it's an essential, basic feature.

Depends who you ask I guess

Re: Why Generics?

#147

Post by phlakaton »

I do not think generics should be added to Go. It does minimalism and it does it tolerably well. Yet I enjoy using generics in other programming languages. If I had my druthers I'd be in Haskell-land in more than my spare time.

Hence, my modest proposal: Add generics, but make it a brand-new programming language with a totally different name.

Sadly, the name Blub is already taken. I propose we call it Glop. Or perhaps: Gong.

Re: Why Generics?

#148

Post by vkou »

shaded-enmity wrote: post #114
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.

> then I have to be familiar with the full semantics of C# generics.

Presumably, by the time the feature ships, the golang.org/doc entry on generics will not consist of just 'lol, they are just like C# generics, docs.microsoft.com, chum'

Re: Why Generics?

#149

Post by sp527 »

This process took way too long. I've already moved back to Python3 and am super happy with it. The truth is most software doesn't really need the performance benefit Golang offers and you can code up something in Python in at least half to a third of the time it would take in Golang. Aside from agility, there's one other benefit that imo matters a lot: reduced LoC. If there's one thing I've learned in my career, it's that you can never really have too few lines of code, provided it achieves the same result as a hypothetical more verbose alternative.

I will admit though that I miss Go's CSP implementation and error-handling convention. Maybe I'll come back to it in the future after they add generics and fix the dependency system.

Re: Why Generics?

#150

Post by LandR »

aczerepinski wrote: post #124
aldanor wrote: post #117

Earlier quoted context omitted.

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…

My work is a Ruby/JS shop, and we have some Go in production as well. We definitely need a little hand holding to ramp anybody new up on the Go codebases. In many cases our devs haven't used types, pointers or any equivalent of goroutines & channels. I've written just barely enough Rust to say there are even more concepts that would be new to my team. Even with Go being comparitvely simpler, I could go either way on…

> In many cases our devs haven't used types, pointers or any equivalent of goroutines & channels.

How do you manage to get a job as a developer without having ever learned this stuff?

Are these people that are just self taught straight to javascript / ruby?

I mean, are CS course nowadays so bad that students come out of them without understanding things like type-theory, pointers etc

Post reply on HN