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

211–220 of 261 posts

Re: Why Generics?

#211

Post by dang »

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…

Oh dear. Personal attacks are not ok on HN, regardless of whom you're attacking. Please stick to the site guidelines, no matter how passionately you feel about the Liskov Substitution Principle.

https://news.ycombinator.com/newsguidelines.html

You obviously have a good point to make, but it needs to be done without firebombs.

Re: Why Generics?

#212

Post by weberc2 »

enneff wrote: post #199
weberc2 wrote: post #194

Earlier quoted context omitted.

Reverse(x)(y) Is that a function that returns a function or a generic Reverse function specialized over type x, invoked with argument y?

When a function returns a function, you rarely just call it immediately in Go. But even if that were common (and maybe it would become common with generics? I'd have to think that through) it is uncommon to have a type name as unrecognizable as 'x'. I've always been a big advocate for unambiguous, clear code, especially in Go, but I don't see a big potential for confusion here.

I don’t want to overstate the problem; I think it is a bit less readable. While types are rarely so indescriptive as “x”, they are often still plenty indescriptive, and I don’t know why we should introduce a syntax that depends on the clarity of type names or the frequency of other potentially ambiguous constructs when we could use a syntax that is unambiguous with no caveats and friendlier/more familiar to the larger body of programmers who have not yet tried Go.

Re: Why Generics?

#213

Post by dragonwriter »

weberc2 wrote: post #196
hajile wrote: post #175

Earlier quoted context omitted.

If go ever showed people the awesomeness of StandardML or Ocaml/ReasonML (and their amazing type systems), I think the language would lose a lot of users.

This is confusingly phrased. Do you mean "If Go people were ever shown ... ML"? I would totally drop Go for an ML language if any of them had a sane syntax, usable build tooling (including native, static compilation by default), and a (single) decent standard library. A super awesome type system is worthless without the basic requirements for scalable software development.

> I would totally drop Go for an ML language if any of them had a sane syntax, usable build tooling (including native, static compilation by default), and a (single) decent standard library.

F# seems to meet all of that except that native static compilation isn't the default (but is available).

Re: Why Generics?

#214

Post by thundergolfer »

gizmo686 wrote: post #179
thundergolfer wrote: post #168

Earlier quoted context omitted.

Why in the case of writing to the array would you want Array[B] < Array[A]?

def writeFirst: (xs: Array[B], x:B): xs[0]=x; var as: Array[A] = ??? var b:B = ??? var a:A = ??? a=b; //This is fine, since B extends A. as[0]=a //Obviously fine, since a:A as[0]=b //This better be fine, otherwise the above 2 lines just punched a hole in our type system. writeFirst(as,b); //If I am allowed to do the above, I should be allowed to do this. For completeness, the opposite example: def getFirst(xs: Array[…

Thanks for the extra detail, but in your `writeFirst` example I don't see a case of `Array[B]` I must be missing something.

Re: Why Generics?

#215

Post by gizmo686 »

thundergolfer wrote: post #214
gizmo686 wrote: post #179

Earlier quoted context omitted.

def writeFirst: (xs: Array[B], x:B): xs[0]=x; var as: Array[A] = ??? var b:B = ??? var a:A = ??? a=b; //This is fine, since B extends A. as[0]=a //Obviously fine, since a:A as[0]=b //This better be fine, otherwise the above 2 lines just punched a hole in our type system. writeFirst(as,b); //If I am allowed to do the above, I should be allowed to do this. For completeness, the opposite example: def getFirst(xs: Array[…

Thanks for the extra detail, but in your `writeFirst` example I don't see a case of `Array[B]` I must be missing something.

Using the word "inherits" might be misleading (as might "extends", which I used). We don't particuarly care that the any actual behaviour/implementation gets re-used.

The core meaning of A I assume you agree agree that my first example ought to type-check (although, as the second example shows, there is an argument to be made that it shouldn't). The question is how does it typecheck?

In the last line, we call writeFirst(as,b). Here, the first parameter has type List[A].

However, writeFirst is declared as taking a first parameter of type List[B]. The fact that this works means that List[A] is-a List[B], which is the defining feature of List[B] If this were not the case, then we would have needed to define writeFirst with a type along the lines of:

writeFirst[X Where we explictly declare that the type parameter of the list is a subtype of B. In this case List[A] could be used not because of the languages decision on variance, but because the program explicitly typechecks with X=A.

Note that this actually changes the return type. In my original example writeFirst(as,b) would have a natural return type of List[B]. However, in this new example, the natural return type would be List[A].

This second example is closer to how ML style languages work.

EDIT: It occurs to me that I was thinking a bit too functional in this. The natural return type of writeFirst is void in (most?) OOP langauges because arrays are mutable. What I wrote assumed that the natural meaning of writeFirst was to construct a new list which replaces the first element.

Re: Why Generics?

#216

Post by ernst_klim »

hajile wrote: post #206
weberc2 wrote: post #196

Earlier quoted context omitted.

This is confusingly phrased. Do you mean "If Go people were ever shown ... ML"? I would totally drop Go for an ML language if any of them had a sane syntax, usable build tooling (including native, static compilation by default), and a (single) decent standard library. A super awesome type system is worthless without the basic requirements for scalable software development.

If StandardML had even a fraction of the money behind go, there would simply be no contest. Ocaml is billed as the pragmatic ML, but the syntax really sucks and nominally typed structs aren't nearly as good. They also have 3 competing standard libraries. Haskell is too ivory tower. Most devs simply can't be bothered. StandardML is that awesome middle. The language choices are pragmatic compared to haskell (mutable re…

>nominally typed structs aren't nearly as good

OCaml structs are structurally typed.

> They also have 3 competing standard libraries.

There is only one standard library, stdlib.

Re: Why Generics?

#217

Post by ernst_klim »

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.

> in ML style languages because they do not make use of inheritence.

Except for OCaml and Scala (or any other ML supporting subtyping), where you could simply define type's variance.

Re: Why Generics?

#218

Post by ernst_klim »

weberc2 wrote: post #196
hajile wrote: post #175

Earlier quoted context omitted.

If go ever showed people the awesomeness of StandardML or Ocaml/ReasonML (and their amazing type systems), I think the language would lose a lot of users.

This is confusingly phrased. Do you mean "If Go people were ever shown ... ML"? I would totally drop Go for an ML language if any of them had a sane syntax, usable build tooling (including native, static compilation by default), and a (single) decent standard library. A super awesome type system is worthless without the basic requirements for scalable software development.

> a sane syntax

Define sane syntax. C-like abomination? At least unlike C it's unambiguous.

Re: Why Generics?

#219

Post by ernst_klim »

Vendan wrote: post #126
Nevermindmine wrote: post #109

Earlier quoted context omitted.

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

Compiler perspective (fast compiles are a core part of Go, IMO), various tradeoffs(fast compile? fast runtime? binary size? Pick 1 or 2), and seeing code bases that get out of control with generics and such. Note that, for all of that, I'm still in favor of adding generics in Go, as I do see the value they can add. I'm just pointing out that "bashing" on Go devs on not knowing what generics are or how they can be use…

> various tradeoffs(fast compile? fast runtime? binary size? Pick 1 or 2)

Interfaces are boxed already, so you've paid the price without having type safety. Simply treat a polymorphic function as if it accepted interface{}.

Re: Why Generics?

#220

Post by mping »

justinhj wrote: post #202
mcguire wrote: post #182

Earlier quoted context omitted.

Once you figure out co- and contravariance, yes. But neurosurgery is straightforward, too. It's just getting from here to there.

99% of the time Scala programmers don't have to worry about variance. I've been using Scala for over 5 years and it's never been more than a cursory concern, the defaults usually work fine. You just have the flexibility to work with it how you want if you need to. To compare it to neurosurgery is simply disingenuous

I think you are generalising. But variance is specifically important for library developers where you have different uses for your code
Post reply on HN