5 ms·

Generics add addition type checking at the the cost of complexity in other areas: syntax, compilation, runtime[0]. Heavily debated there, but what they are try

by kyrra 12y ago

Generics add addition type checking at the the cost of complexity in other areas: syntax, compilation, runtime[0]. Heavily debated there, but what they are trying to get at is that generics have a cost associated with them, adding them is not free. The Go team is trying to search to see if there is some better way to solve this problem right now. As well, from what I've heard of Java's generics implementation, it add a huge amount of complexity to javac and the JRE. The Go team is small and probably didn't have the resources to do it out the gate. [0] http://research.swtch.com/generic http://research.swtch.com/generic

tomp 12y ago
I don't think you understood my point. To repeat: there is no cost in adding generics to Go, because they are already there! They are just non-generic (pun intended) - you cannot add it to every type, only to "blessed" types - arrays/slices, channels and maps.
- burntsushi 12y ago
  > To repeat: there is no cost in adding generics to Go, because they are already there! Could you please stop spreading this nonsense?[1] Generics aren't free. You will always pay for it in terms of some combination of implementation complexity, runtime performance and compiler performance. [1] - https://news.ycombinator.com/item?id=8316995 https://news.ycombinator.com/item?id=8316995
  - tomp 12y ago
    I'm sorry. In all honesty, I have no idea how generics are currently implemented in Go. If you know, I'd kindly ask you to explain why you think the current implementation could not be extended to user-defined types. > Generics aren't free. You will always pay for it in terms of some combination of implementation complexity, runtime performance and compiler performance. I don't argue about implementation complexity and compiler performance, I'm just saying that I assume that most that complexity is already present in the Go compiler. However, I think that saying that generics have runtime performance cost is disingenuous. It's like saying that functions aren't free. Now, obviously it's possible to program without function by using loops, gotos or inlining code. However, if you want to make your program more abstract, you'll end up implementing functions, along with calling conventions, register saving, varargs, ... It's easier if the compiler does that for you (also, sometimes the compiler will compile functions into loops, gotos or inlined code, reducing the performance penalty). It's the same with generics. If you have an algorithm that you want to use with different data types, you can either (1) implement it multiple times, or (2) manually box and unbox all values. That's exactly what the compiler can do for you if you write the code using generics. The fact that most compilers use just one of these strategies is not a deficiency of generics, but the deficiency of compilers. Both Scala and .Net use both specialization and boxing. Therefore, in all honesty, I really see no additional runtime cost to generics that wouldn't be present in equivalent non-generic code.
    - burntsushi 12y ago
      > It's like saying that functions aren't free. They aren't free... I literally don't know what to say here. The whole point is to analyze the trade offs of generics rather than start out with a judgment that they are always worth it. In order to have generics supported in a language, you must pay for it some way or another. If you just box all of the values like (I think) you're suggesting and provide compiler support for it, then programs that use generics are going to pay a cost in runtime performance compared to programs that don't use them. In other implementations of generics, it's possible to remove that runtime cost (or almost remove), but usually at the cost of something else like implementation complexity or compiler speed. Programs that use generics with that implementation choice won't pay a runtime cost compared to programs that don't use them. This obviously has a significant impact on the decision procedure of whether to use generics or not at any given point in your program. And yes, absolutely, saying generics has a cost is exactly like saying functions have a cost. The only difference between them is that there is clearly still a substantive amount of disagreement over whether full blown generics is always worth its weight in value (compared to the cost of not having them). Currently, Go does not have anything resembling the term "generics." (Except for a few built in types and functions defined in the language specification.)
bad_user 12y ago
Generics added complexity to Java because of: 1. if you have sub-typing in the language, then you'll naturally have to think of co/contra-variance, which leads us to ... 2. Java had backwards compatibility concerns, for example they were unwilling to deprecate the standard collections, so they chose to implement use-site variance with wildcards There are several problems there - first of all you cannot declare variance rules on the classes themselves, even though there are legitimate use-cases for that, like immutable data-structures have no problem in being covariant. Hence generics in Java are much less useful than they would be with declaration-site variance. Then subtyping + variance, especially with wildcards which are basically existential types, is undecidable, so by definition people have a hard time in producing a reliable compiler. Here's a fun example that could crash a compiler: class C<P> implements List<List<? super C<C<P>>>> {} And doesn't that suck? But seriously, Java's designers could have chosen a better, saner path. Declaration-site variance is so much better. And we aren't talking about really expressive type-systems, with higher-kinded types and type-2 polymorphism, for starters the basics would do just fine. I mean, Go's standard data-structures are generified. Why not provide the same capability to its users? This situation is exactly like with Java's arrays.

by kyrra 12y ago

tomp 12y ago

I don't think you understood my point. To repeat: there is no cost in adding generics to Go, because they are already there! They are just non-generic (pun intended) - you cannot add it to every type, only to "blessed" types - arrays/slices, channels and maps.

burntsushi 12y ago
> To repeat: there is no cost in adding generics to Go, because they are already there! Could you please stop spreading this nonsense?[1] Generics aren't free. You will always pay for it in terms of some combination of implementation complexity, runtime performance and compiler performance. [1] - https://news.ycombinator.com/item?id=8316995 https://news.ycombinator.com/item?id=8316995
- tomp 12y ago
  I'm sorry. In all honesty, I have no idea how generics are currently implemented in Go. If you know, I'd kindly ask you to explain why you think the current implementation could not be extended to user-defined types. > Generics aren't free. You will always pay for it in terms of some combination of implementation complexity, runtime performance and compiler performance. I don't argue about implementation complexity and compiler performance, I'm just saying that I assume that most that complexity is already present in the Go compiler. However, I think that saying that generics have runtime performance cost is disingenuous. It's like saying that functions aren't free. Now, obviously it's possible to program without function by using loops, gotos or inlining code. However, if you want to make your program more abstract, you'll end up implementing functions, along with calling conventions, register saving, varargs, ... It's easier if the compiler does that for you (also, sometimes the compiler will compile functions into loops, gotos or inlined code, reducing the performance penalty). It's the same with generics. If you have an algorithm that you want to use with different data types, you can either (1) implement it multiple times, or (2) manually box and unbox all values. That's exactly what the compiler can do for you if you write the code using generics. The fact that most compilers use just one of these strategies is not a deficiency of generics, but the deficiency of compilers. Both Scala and .Net use both specialization and boxing. Therefore, in all honesty, I really see no additional runtime cost to generics that wouldn't be present in equivalent non-generic code.
  - burntsushi 12y ago
    > It's like saying that functions aren't free. They aren't free... I literally don't know what to say here. The whole point is to analyze the trade offs of generics rather than start out with a judgment that they are always worth it. In order to have generics supported in a language, you must pay for it some way or another. If you just box all of the values like (I think) you're suggesting and provide compiler support for it, then programs that use generics are going to pay a cost in runtime performance compared to programs that don't use them. In other implementations of generics, it's possible to remove that runtime cost (or almost remove), but usually at the cost of something else like implementation complexity or compiler speed. Programs that use generics with that implementation choice won't pay a runtime cost compared to programs that don't use them. This obviously has a significant impact on the decision procedure of whether to use generics or not at any given point in your program. And yes, absolutely, saying generics has a cost is exactly like saying functions have a cost. The only difference between them is that there is clearly still a substantive amount of disagreement over whether full blown generics is always worth its weight in value (compared to the cost of not having them). Currently, Go does not have anything resembling the term "generics." (Except for a few built in types and functions defined in the language specification.)

bad_user 12y ago

Generics added complexity to Java because of: 1. if you have sub-typing in the language, then you'll naturally have to think of co/contra-variance, which leads us to ... 2. Java had backwards compatibility concerns, for example they were unwilling to deprecate the standard collections, so they chose to implement use-site variance with wildcards There are several problems there - first of all you cannot declare variance rules on the classes themselves, even though there are legitimate use-cases for that, like immutable data-structures have no problem in being covariant. Hence generics in Java are much less useful than they would be with declaration-site variance. Then subtyping + variance, especially with wildcards which are basically existential types, is undecidable, so by definition people have a hard time in producing a reliable compiler. Here's a fun example that could crash a compiler: class C<P> implements List<List<? super C<C<P>>>> {} And doesn't that suck? But seriously, Java's designers could have chosen a better, saner path. Declaration-site variance is so much better. And we aren't talking about really expressive type-systems, with higher-kinded types and type-2 polymorphism, for starters the basics would do just fine. I mean, Go's standard data-structures are generified. Why not provide the same capability to its users? This situation is exactly like with Java's arrays.