| What is so hard about adding generics? | Tim Chirananthavat | 28/11/14 19:21 | Seriously, I don't understand why is it so hard to add generics to go. You might say that you don't need it, but library writers would definitely want generics. A language cannot be successful without good libraries. From what I have read (e.g. https://golang.org/doc/faq#generics "Generics are convenient but they come at a cost in complexity in the type system and run-time."), there seems to be two types of problems about generics: (1) syntax and semantics (2) implementation and performance. However, both don't look like real problems to me. As for syntax and semantics, the go interface system is already pretty similar to haskell's typeclasses, so I think it should be relatively easy to model generics after haskell's polymorphism. As for implementation and performance, it probably wouldn't be much different from the existing implementation of interfaces, which is already sort of partially implemented generics. Did I miss anything? Is generics really that problematic? |
| Re: [go-nuts] What is so hard about adding generics? | Michael Jones | 28/11/14 19:52 | You've missed a few years of discussion on the topic. A search through the group archive will be interesting for you. You also missed "go generate", which is new scaffolding for the general task of generated code. -- |
| Re: What is so hard about adding generics? | Dave Cheney | 28/11/14 19:53 | Generics cannot be added to the language without also adding support for inheritance, aka subtyping. Go does not support inheritance so generics cannot be added. It's as simple as that. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Dave Cheney | 28/11/14 22:10 | Most of the arguments for adding generic to Go is to support
collection types, sets, tries, etc. That isn't very interesting to me, I'm sure it's interesting to others, but not to me; maps and slices work just fine. What is interesting to me is writing generic functions, the simple example is Max. I want to write a Max function that _only works on numbers_. It isn't sufficient to say func Max(a, b T) T because that does not constrain the types that can be substituted for T. Ideally what you would write is func Max(a, b <T extends Number>) (T extends Number> To make up a random syntax. But in Go we cannot write that because there is no supertype of int, uint, float64, complex128, etc. Even if there were, is Number the supertype of type MyInt int ? And, even if there was some notion of some kinds of types being grouped together as numbers, that still leaves the problem of overloading the arguments to a function. Ie x, y := 100, 200 a, b := 1.0, 3.14 fmt.Println(Max(x,y), Max(a,b)) Go doesn't allow functions to be overloaded based on their arguments, so some kind of templated code generation (which I think is what Rust has), wouldn't work either. You can't have two Max functions defined either by the programmer, or by the compiler in the same package. Now that might be solvable, if the compiler appended some hidden suffix, but that introduces even more problems max := Max f(max) What is the type of Max ? If max is passed as a value what is the type of the argument, if the arguments to Max are not specified til it is invoked. Dave On Sat, Nov 29, 2014 at 4:40 PM, Chandru <chand...@gmail.com> wrote: > I have read about the complexity in adding generics and Russ' Generic > Dilemma, but I've never come across inheritance being necessary for it. > > Can you explain this a little more? For example, rust did not have > inheritance in the sense of Java/C++ sub-classes, but has always had > generics. > > -- > Chandra Sekar.S |
| Re: What is so hard about adding generics? | wkharold | 28/11/14 22:20 | Yes, and yes. If it was easy, even relatively easy, don't you think go's designers would have included generics? Per Michael Jones, generics have been discussed extensively on this list since go's public release. Proposals and "solutions" are not in short supply. Workable ones, that don't permanently deface the language, however, have proved hard to come by. |
| Re: [go-nuts] Re: What is so hard about adding generics? | minux | 28/11/14 23:21 | On Sat, Nov 29, 2014 at 1:09 AM, Dave Cheney <da...@cheney.net> wrote:Most of the arguments for adding generic to Go is to support In fact, even type safe generic collections are hard. Many of the existing proposals don't even support list of list of T. I'm sure it's interesting to others, but not to me; maps and slices |
| Re: [go-nuts] Re: What is so hard about adding generics? | Tay | 28/11/14 23:24 | I would add that it can make concurrency difficult. And generic collections are probably difficult to do because of alignment and type safety guarantees. I still wish we could have some generic collections at some point though, and think that it could perhaps be doable via code generation. Importing a package that initializes a type at runtime which is basically a struct of arrays of some kind of predetermined size. That's just an idea though. And funnily enough, my need for generic functions is quite limited since we have interfaces (for now at least, but I'm pretty sure I'm doing less interesting stuff than Dave). I have genericity of behaviour in my current use cases. I just wish sometimes for more capabilities around the handling of types at runtime but it's coming incrementally in the reflect pkg and I have the good feeling we will have a way to deal with that in the future. |
| Re: [go-nuts] Re: What is so hard about adding generics? | rog | 29/11/14 00:04 | I think you have chosen a particularly problematic example there. I personally think that it would be fine to add generics to Go without providing the capability to perform arithmetic operations directly on generically typed values. That's the approach taken with interfaces (with the exception of ==) and it works well. I don't see that subtype polymorphism is necessary or desirable in Go-with-generics. My worry about generics is that everyone will instantly carry across their design patterns from other languages and we could lose the first order simplicity that most Go code currently exhibits. |
| Re: [go-nuts] Re: What is so hard about adding generics? | ehedgehog | 29/11/14 01:15 | On 29 November 2014 at 03:53, Dave Cheney <da...@cheney.net> wrote:I don't see why; I'd regard ML's polymorphic functions and datatypes as providing (one style of) generics, and there's no inheritance there and the subtyping is "you can replace this type variable uniformly with with this type". "inheritance" and "subtyping" aren't the same thing. It's never that simple. Chris -- Chris "allusive" Dollin |
| Re: What is so hard about adding generics? | Gyu-Ho Lee | 29/11/14 01:28 | Rob Pike answer for this: http://youtu.be/u-kkf76TDHE?t=34m41s |
| Re: [go-nuts] What is so hard about adding generics? | Tim Chirananthavat | 29/11/14 01:34 | I already tried to search for the discussion about generics, but I just cannot find one that addresses this issue properly. Most of the stuff that I find are relatively recent posts. Can you post a link to a good discussion? |
| Re: [go-nuts] What is so hard about adding generics? | ehedgehog | 29/11/14 01:37 | On 29 November 2014 at 03:21, Theemathas Chirananhavat
<theem...@gmail.com> wrote:*Requiring* generics to be implemented with uniform sizing and hence pointers (which are buried in interfaces) is *specifically* not what the Go team want to do. Yes. The devil is in the details. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Tim Chirananthavat | 29/11/14 01:41 | In that case, the type of Max (and also the type of max) would be something like "[for_all T assignable_to Number] func(T,T) T". "Number" would be something similar to a "built in psudo-interface type", and "assignable_to" would be a generalized version of the criteria at http://golang.org/ref/spec#Assignability |
| Re: [go-nuts] Re: What is so hard about adding generics? | Dave Cheney | 29/11/14 01:47 | But interfaces only specify behaviour, not data. This is the "boxing" issue that rsc referred to. If Number was an interface that could hold any numeric type it would have to be 128 bits wide to accommodate the largest numeric type that Go supports. Additionally if this Number interface was some sort of built in, how would it be extensible for other user declared numeric types like type Complex64 { real, image float32 } Ultimately the reason I believe Go 1.x will not have generics is the overwhelming number of limitations and edge cades like these. You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Tim Chirananthavat | 29/11/14 01:48 | Well... suppose you want a function that takes a slice of slices of Ts and returns a slice of slices of Ts, I can do something like: "[for_all T] func foo([][]T) ([][]T) {}" Right? If you are talking about implementation details, that another story, though. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Tim Chirananthavat | 29/11/14 01:53 | How does generic programming make concurrency difficult? How is generic programming more difficult than interfaces about alignment and type safety? Generic programming is basically a type-safe version of "interface{}" If you think you can use interfaces to do anything practical, how do you write a type-safe function that reverses a slice of anything? |
| Re: [go-nuts] What is so hard about adding generics? | Tim Chirananthavat | 29/11/14 01:56 | How are generics different from templates in that respect? |
| Re: [go-nuts] Re: What is so hard about adding generics? | Tim Chirananthavat | 29/11/14 02:11 | Python's approach to extend built in functions/operators (e.g. len(), >, ==, +) to user-defined types is to use a specially named method. See https://docs.python.org/3/reference/datamodel.html#special-method-names and https://docs.python.org/3/reference/datamodel.html#emulating-numeric-types Haskell's approach is to treat operators like functions with 2 arguments and defining the "Num" and "Integral" typeclasses (similar to go's interfaces, but they must be explicit). These typeclass requires a few operators/functions to be defined. See: http://hackage.haskell.org/package/base-4.7.0.1/docs/Prelude.html#t:Num and http://hackage.haskell.org/package/base-4.7.0.1/docs/Prelude.html#t:Integral (if you know haskell) If you think it is too complex for Go 1.x, I think it might be the defining feature of Go 2.0. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Dave Cheney | 29/11/14 02:17 | Right, so now you are talking about adding operator overloading to the language. This is why Go does not have generics, not because they are useless or a bad idea, but because implementing them well (there is no interest in a half baked implementation) would be such a fundamental change to the language that it is likely the core values of the language would not survive. |
| Re: What is so hard about adding generics? | Tim Chirananthavat | 29/11/14 02:17 | Thank you. I would like to know the reason the language designer made it this way. There is one problem, though. My computer's speakers are acting odd today. I can't hear what he said. :( |
| Re: [go-nuts] Re: What is so hard about adding generics? | Tim Chirananthavat | 29/11/14 02:18 | Kudos for mention of ML |
| Re: [go-nuts] What is so hard about adding generics? | kortschak | 29/11/14 02:24 | On Sat, 2014-11-29 at 01:34 -0800, Theemathas Chirananhavat wrote:This is a good starting point: http://research.swtch.com/generic There are many proposals where various issues have been raised though. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Tim Chirananthavat | 29/11/14 02:33 | What is the difference between "operator overloading" and "methods with the same name" anyway? Go already uses "methods with the same name" for interfaces, and the interface system is already (IMHO) a "half-baked implementation" of generics. One more approach to the problem: In scala, "a + b" and "a.+(b)" are the same. (That is a method called "+") |
| Re: What is so hard about adding generics? | Starfish | 29/11/14 02:33 | Agreed! Generics is needed, and Go is not "sort of" generic. If it was, someone could implement something similar to LINQ. |
| Re: [go-nuts] What is so hard about adding generics? | Tim Chirananthavat | 29/11/14 02:34 | Thank you. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Gordon Klaus | 29/11/14 02:35 | On Saturday, November 29, 2014 10:53:02 AM UTC+1, Theemathas Chirananhavat wrote:
This doesn't exactly answer your question, but: http://golang.org/pkg/sort/#Reverse Actually, it does more than you ask for; it reverses any ordered collection type, not just slices. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Dave Cheney | 29/11/14 02:37 | On Sat, Nov 29, 2014 at 9:33 PM, Theemathas Chirananhavat
<theem...@gmail.com> wrote: > What is the difference between "operator overloading" and "methods with the > same name" anyway? A vast difference, just ask the go-num folks who have been asking for operator overloading for 5 years. > Go already uses "methods with the same name" for interfaces, and the > interface system is already (IMHO) a "half-baked implementation" of > generics. > > One more approach to the problem: In scala, "a + b" and "a.+(b)" are the > same. (That is a method called "+") > > On Saturday, November 29, 2014 5:17:07 PM UTC+7, Dave Cheney wrote: >> >> Right, so now you are talking about adding operator overloading to the >> language. >> >> This is why Go does not have generics, not because they are useless or a >> bad idea, but because implementing them well (there is no interest in a half >> baked implementation) would be such a fundamental change to the language >> that it is likely the core values of the language would not survive. >> >> On 29 Nov 2014 21:12, "Theemathas Chirananhavat" <theem...@gmail.com> >> wrote: >>> >>> Python's approach to extend built in functions/operators (e.g. len(), >, >>> ==, +) to user-defined types is to use a specially named method. See >>> https://docs.python.org/3/reference/datamodel.html#special-method-names and >>> https://docs.python.org/3/reference/datamodel.html#emulating-numeric-types >>> >>> Haskell's approach is to treat operators like functions with 2 arguments >>> and defining the "Num" and "Integral" typeclasses (similar to go's >>> interfaces, but they must be explicit). These typeclass requires a few >>> operators/functions to be defined. See: >>> http://hackage.haskell.org/package/base-4.7.0.1/docs/Prelude.html#t:Num and >>> http://hackage.haskell.org/package/base-4.7.0.1/docs/Prelude.html#t:Integral >>> (if you know haskell) >>> >>> If you think it is too complex for Go 1.x, I think it might be the >>> defining feature of Go 2.0. >>> >>> On Saturday, November 29, 2014 4:47:29 PM UTC+7, Dave Cheney wrote: >>>> >>>> But interfaces only specify behaviour, not data. This is the "boxing" >>>> issue that rsc referred to. >>>> >>>> If Number was an interface that could hold any numeric type it would >>>> have to be 128 bits wide to accommodate the largest numeric type that Go >>>> supports. >>>> >>>> Additionally if this Number interface was some sort of built in, how >>>> would it be extensible for other user declared numeric types like type >>>> Complex64 { real, image float32 } >>>> >>>> Ultimately the reason I believe Go 1.x will not have generics is the >>>> overwhelming number of limitations and edge cades like these. >>>> >>>> On 29 Nov 2014 20:42, "Theemathas Chirananhavat" <theem...@gmail.com> >>>> wrote: >>>>> >>>>> In that case, the type of Max (and also the type of max) would be >>>>> something like "[for_all T assignable_to Number] func(T,T) T". >>>>> >>>>> "Number" would be something similar to a "built in psudo-interface >>>>> type", and "assignable_to" would be a generalized version of the criteria at >>>>> http://golang.org/ref/spec#Assignability >>>>> >>>>> On Saturday, November 29, 2014 1:10:18 PM UTC+7, Dave Cheney wrote: >>>>>> >>>>>> Most of the arguments for adding generic to Go is to support >>>>>> collection types, sets, tries, etc. That isn't very interesting to me, >>>>>> I'm sure it's interesting to others, but not to me; maps and slices >>>>>> work just fine. >>>>>> >>>>>> What is interesting to me is writing generic functions, the simple >>>>>> example is Max. I want to write a Max function that _only works on >>>>>> numbers_. It isn't sufficient to say >>>>>> >>>>>> func Max(a, b T) T >>>>>> >>>>>> because that does not constrain the types that can be substituted for >>>>>> T. Ideally what you would write is >>>>>> >>>>>> func Max(a, b <T extends Number>) (T extends Number> >>>>>> >>>>>> To make up a random syntax. But in Go we cannot write that because >>>>>> there is no supertype of int, uint, float64, complex128, etc. Even if >>>>>> there were, is Number the supertype of type MyInt int ? >>>>>> >>>>>> And, even if there was some notion of some kinds of types being >>>>>> grouped together as numbers, that still leaves the problem of >>>>>> overloading the arguments to a function. Ie >>>>>> >>>>>> x, y := 100, 200 >>>>>> a, b := 1.0, 3.14 >>>>>> >>>>>> fmt.Println(Max(x,y), Max(a,b)) >>>>>> >>>>>> Go doesn't allow functions to be overloaded based on their arguments, >>>>>> so some kind of templated code generation (which I think is what Rust >>>>>> has), wouldn't work either. You can't have two Max functions defined >>>>>> either by the programmer, or by the compiler in the same package. >>>>>> >>>>>> Now that might be solvable, if the compiler appended some hidden >>>>>> suffix, but that introduces even more problems >>>>>> >>>>>> max := Max >>>>>> f(max) >>>>>> >>>>>> What is the type of Max ? If max is passed as a value what is the type >>>>>> of the argument, if the arguments to Max are not specified til it is >>>>>> invoked. >>>>>> >>>>>> Dave >>>>>> >>>>>> On Sat, Nov 29, 2014 at 4:40 PM, Chandru <chand...@gmail.com> wrote: >>>>>> > I have read about the complexity in adding generics and Russ' >>>>>> > Generic >>>>>> > Dilemma, but I've never come across inheritance being necessary for >>>>>> > it. >>>>>> > >>>>>> > Can you explain this a little more? For example, rust did not have >>>>>> > inheritance in the sense of Java/C++ sub-classes, but has always had >>>>>> > generics. >>>>>> > >>>>>> > -- >>>>>> > Chandra Sekar.S >>>>>> > >>>>>> > On Sat, Nov 29, 2014 at 9:23 AM, Dave Cheney <da...@cheney.net> >>>>>> > wrote: >>>>>> >> >>>>>> >> Generics cannot be added to the language without also adding >>>>>> >> support for >>>>>> >> inheritance, aka subtyping. Go does not support inheritance so >>>>>> >> generics >>>>>> >> cannot be added. >>>>>> >> >>>>>> >> It's as simple as that. >>>>>> >> >>>>>> >> >>>>>> >> On Saturday, 29 November 2014 14:21:06 UTC+11, Theemathas >>>>>> >> Chirananhavat >>>>>> >> wrote: >>>>>> >>> >>>>>> >>> Seriously, I don't understand why is it so hard to add generics to >>>>>> >>> go. >>>>>> >>> You might say that you don't need it, but library writers would >>>>>> >>> definitely >>>>>> >>> want generics. A language cannot be successful without good >>>>>> >>> libraries. >>>>>> >>> >>>>>> >>> From what I have read (e.g. https://golang.org/doc/faq#generics >>>>>> >>> "Generics >>>>>> >>> are convenient but they come at a cost in complexity in the type >>>>>> >>> system and >>>>>> >>> run-time."), there seems to be two types of problems about >>>>>> >>> generics: (1) >>>>>> >>> syntax and semantics (2) implementation and performance. However, >>>>>> >>> both don't >>>>>> >>> look like real problems to me. >>>>>> >>> >>>>>> >>> As for syntax and semantics, the go interface system is already >>>>>> >>> pretty >>>>>> >>> similar to haskell's typeclasses, so I think it should be >>>>>> >>> relatively easy to >>>>>> >>> model generics after haskell's polymorphism. >>>>>> >>> >>>>>> >>> As for implementation and performance, it probably wouldn't be >>>>>> >>> much >>>>>> >>> different from the existing implementation of interfaces, which is >>>>>> >>> already >>>>>> >>> sort of partially implemented generics. >>>>>> >>> >>>>>> >>> Did I miss anything? Is generics really that problematic? >>>>>> >> >>>>>> >> -- >>>>>> >> You received this message because you are subscribed to the Google >>>>>> >> Groups >>>>>> >> "golang-nuts" group. >>>>>> >> To unsubscribe from this group and stop receiving emails from it, >>>>>> >> send an >>>>>> >> email to golang-nuts...@googlegroups.com. >>>>>> >> For more options, visit https://groups.google.com/d/optout. >>>>>> > >>>>>> > >>>>> >>>>> -- >>>>> You received this message because you are subscribed to a topic in the >>>>> Google Groups "golang-nuts" group. >>>>> To unsubscribe from this topic, visit >>>>> https://groups.google.com/d/topic/golang-nuts/smT_0BhHfBs/unsubscribe. >>>>> To unsubscribe from this group and all its topics, send an email to >>>>> golang-nuts...@googlegroups.com. >>>>> For more options, visit https://groups.google.com/d/optout. >>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "golang-nuts" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/golang-nuts/smT_0BhHfBs/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> golang-nuts...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/smT_0BhHfBs/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. |
| Re: [go-nuts] Re: What is so hard about adding generics? | kortschak | 29/11/14 02:38 | Us? I don't think so.
|
| Re: [go-nuts] Re: What is so hard about adding generics? | Gordon Klaus | 29/11/14 02:39 | I have to correct myself: sort.Reverse doesn't do what I expected. But it's easy to see how you could implement generic reversal for any type implementing sort.Interface. |
| Re: What is so hard about adding generics? | Egon | 29/11/14 02:46 | On Saturday, 29 November 2014 05:21:06 UTC+2, Theemathas Chirananhavat wrote: The most important thing... what real world problem are you trying to solve with generics that you cannot currently solve with Go? + Egon |
| Re: What is so hard about adding generics? | Egon | 29/11/14 02:48 | On Saturday, 29 November 2014 12:33:37 UTC+2, Starfish wrote:
You mean like: http://godoc.org/gopkg.in/mgo.v2 or http://godoc.org/github.com/coocood/qbs?
|
| Re: [go-nuts] Re: What is so hard about adding generics? | Sebastien Binet | 29/11/14 02:57 | On Sat, Nov 29, 2014 at 11:37 AM, Dave Cheney <da...@cheney.net> wrote:I don't think go-num did that. we proposed to have a kind of multi-dimensional slice, but left operator overloading off the table (of the "table" proposal) -s |
| Re: [go-nuts] Re: What is so hard about adding generics? | ehedgehog | 29/11/14 03:00 | On 29 November 2014 at 10:46, egon <egon...@gmail.com> wrote:Go's as Turning-complete as any other programming language. The question isn't whether you /can/ solve he problem without generics, it's whether having generics [1] makes solving problems clearer or more efficient or subject to better checking by tools or more fun to write in. Chris [1] For some value of "generics". And angsting about what kind of generics we actually want is part of the problem ... -- Chris "allusive" Dollin |
| Re: [go-nuts] Re: What is so hard about adding generics? | Tim Chirananthavat | 29/11/14 03:01 | Actually, that library demonstrates the problem caused by the lack of generics. From https://golang.org/src/pkg/sort/sort.go lines 233-237: (start code) type IntSlice []int func (p IntSlice) Len() int { return len(p) } func (p IntSlice) Less(i, j int) bool { return p[i] < p[j] } func (p IntSlice) Swap(i, j int) { p[i], p[j] = p[j], p[i] } (end code) What if you want to sort "[]int16" or "[]int32" or "[]int64" or "[]uint16" or "[]uint32" or "[]uint64"? You would have to copy and paste most of that code. If you want to sort "[]Time"? One more duplication. For tasks more complicated than that, it would quickly become unmanageable. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Dave Cheney | 29/11/14 03:01 | I am very sorry. I spoke out of turn, this is not my area of expertise.
|
| Re: [go-nuts] Re: What is so hard about adding generics? | Gordon Klaus | 29/11/14 03:26 |
Yes, you have to write a tiny bit of boilerplate code to make a type sortable. I don't personally find it worth complaining about.
A little duplication never hurt anyone; it is possible to go overboard with the DRY principle. In reality, the duplication of three single-line methods is not unmanageable.
|
| Re: [go-nuts] Re: What is so hard about adding generics? | kortschak | 29/11/14 03:36 | And by defining a LenSwapper interface, you only need two lines per type.
|
| Re: [go-nuts] Re: What is so hard about adding generics? | Tay | 29/11/14 03:45 | The reason is that you cannot guarantee that your generic type holds into a single machine word. Therefore it will have a huge impact on performance. That's the reason why using collection of interfaces is not necessarily a good thing too. Besides, the indirection (an interface is basically 2 pointers) does not guarantee contiguity in memory. If you want, template-like generics, then we are going to fight (just kidding, that may be a personal thing, but <int,float> is a code uglifier. Besides my personal opinion, it will make some kind of concurrency programming difficult too) A lot of us add the same feelings about generics. But after a few months / weeks ? / days ?, you realize that maybe you don't need them as much as you thought anyway. Now I'm not saying that they are a few things that I think couldn't make life easier, but I don't think I would ever want to trade the simplicity of the language as it is for a code writing convenience that I don't need most of times. If I have to write more code, from time to time, so be it. And I'm sure that the way to solve the issue of generic programming is actually not in having generics. On Saturday, November 29, 2014 9:53:02 AM UTC, Theemathas Chirananhavat wrote:
|
| Re: [go-nuts] Re: What is so hard about adding generics? | Milan P. Stanic | 29/11/14 05:01 | On Sat, 2014-11-29 at 03:45, Tahir wrote:
[...] > Now I'm not saying that they are a few things that I think couldn't make+1 (Nicely said.) [...] |
| Re: [go-nuts] Re: What is so hard about adding generics? | Gyu-Ho Lee | 29/11/14 10:50 | +99999 please don't add generics. I don't want to go back to c++ |
| Re: [go-nuts] Re: What is so hard about adding generics? | ehedgehog | 29/11/14 11:02 | On 29 November 2014 at 18:50, Gyu-Ho Lee <gyuh...@gmail.com> wrote:Adding "generics" [1] doesn't enforce committing to the C++ model. Chris [1] Of some kind. It's a woolly term. -- Chris "sheepish" Dollin |
| Re: [go-nuts] Re: What is so hard about adding generics? | Sebastien Binet | 29/11/14 11:36 | On Sat, Nov 29, 2014 at 8:02 PM, chris dollin <ehog....@googlemail.com> wrote:a wibbly-wobbly timely-wimely [term]. -s |
| Re: [go-nuts] Re: What is so hard about adding generics? | Tay | 29/11/14 14:23 | From the recent C++ conf I've watched, it looked `to me` more like C++ was planning to move toward Go ;-) Just to be clear, I'm wary of the 'generics' from the other languages but I would be in favor of any solution that doesn't penalize everyone and looks good (I mean, really looks clear visually in terms of code). Reified types with the first class functions of Go could be quite cool. Have to see where the reflect pkg goes. But you can really fiddle with interfaces. (that will require to not use the builtin types but define your own types on top.. There is still the issue of doing operations on objects that implement the same interface but are different, yet I guess an "explicit" conversion would have to happen in those cases, anyway). Most of the time, it's the need for genericity of the return value of functions that is a problem. A bit like that ( please don't chastize me : http://play.golang.org/p/9rR3Askxpe ) although I understand that you have to redefine the operators, that a simple computation now looks ugly etc etc. really just a mere example.
|
| Re: [go-nuts] Re: What is so hard about adding generics? | Chandra Sekar S | 29/11/14 15:00 | |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian Lance Taylor | 29/11/14 15:18 | On Sat, Nov 29, 2014 at 3:01 AM, Theemathas ChirananhavatThat is hyperbolic. Copying three lines per type that needs to be sorted is clearly not ideal. However, it will never become unmanageable. Copying becomes unmanageable when there is a series of patches that must be applied to each copy. These three lines are simple enough that that will never happen. I agree that this is a case that would benefit from some form of generics, but this can't be the main argument for adopting them. Ian |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian Lance Taylor | 29/11/14 15:24 | On Sat, Nov 29, 2014 at 2:33 AM, Theemathas Chirananhavat1) Syntax. 2) The number of surprises when reading code. No, the interface system is a fully based implementation of structural typing. Most people take generics to imply some variety of parametric polymorphism, which is different. I agree that if Go were to adopt operator overloading it would be through a mechanism along those lines. Ian |
| Re: [go-nuts] What is so hard about adding generics? | Ian Lance Taylor | 29/11/14 15:39 | On Fri, Nov 28, 2014 at 7:21 PM, Theemathas ChirananhavatAnd yet, they are real problems. If you are really interested in this, I suggest that rather than simply stating that they are easy, you spend some time building a full proposal. But you should only do that for fun, not because you hope that it will be adopted. Personally I would say that the main difficulties with generics in Go are 1) types are different sizes and support different syntactic operations, 2) Go is a fully compiled language, 3) fast compilation is considered to be very important, 4) simplicity is considered to be very important (Go programs should be easy to understand or, to put it another way, the Obfuscated Go Contest should be boring). Ian |
| Re: [go-nuts] Re: What is so hard about adding generics? | Bakul Shah | 29/11/14 15:44 | You're probably thinking of the "What is Generic Programming"
paper by Dos Reis and Järvi that looks this question in exhaustive/ing detail but I think most people who bleat on about "generics" would agree with the Wikipedia definition: In the simplest definition, generic programming is a style of computer programming in which algorithms are written in terms of types to-be-specified-later that are then instantiated when needed for specific types provided as parameters. Of course this too is fuzzy but you have shaved the sheep pretty close! Examples: type T // we just say T is a type but nothing else about it ... func Max(a, b T) T { if a > b { return a }; return b } If Max is used on objects of a type for which > is not defined, this can be caught at compile time. type T1, T2 ... func Map(f func(T1)T2, in []T1) []T1 { out := make([]T2, len(in)) for i,val := range in { out[i] = f(val) } return out } ... sq := func (x int) { return x * x } fmt.Printf("%v\n", Map(sq, []int{1,2,3,4,5})) // should print [1 4 9 16 25] ... func Fold(f func(T1,T2)T1, z T1, in []T2) []T1 { out := make([]T1, len(in)+1) out[0] = z for i,val := range in { out[i+1] = f(out[i], val) } return out } ... plus := func (x float64, y int) float64 { return x + float64(y) } fmt.Printf("%v\n", Fold(plus, 0.5, []int{1,2,3,4,5})) // should print [0.5 1.5 3.5 6.5 10.5 15.5] etc. But given Go's design, type parameterization can never get as complicated as C++ templates. Of course, any such design has to dovetail with Go's existing features and that is a tall order. And generic will make the compiler more complicated (though this might be easier in Go -- with each generic object you associate a "generator" process that accepts concrete types and returns an error or a concrete object). PS: I don't like the way I declared T, T1 & T2 above as their scope is global, but Max, Map and Fold just need local defns. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Matt Sherman | 29/11/14 16:50 | v4 of my gen tool (will merge to master this week) has the notion of Numeric, Comparable and Ordered type constraints for exactly this purpose. So one can implement a Max or a Sum and target only types meeting certain constraints. The work to determine such "type classes" is done by the excellent types package.
|
| Re: [go-nuts] Re: What is so hard about adding generics? | Jesper Louis Andersen | 29/11/14 17:05 | I'm almost positive you can take the interface concept as a system of structural subtyping. A ReadCloser is a Reader and a Closer, so it is a subtype of both (it is more specific, hence a subtype). Whenever the code mandates a Reader, you can use something of type ReadCloser as well. In general, inheritance != subtype, the latter being a more general concept. The problems has to do with: * compilation speed * linking speed and/or performance of linked programs * complexity: Benjamin C. Pierce, "Types and programming languages" chapter 15 (subtyping) and chapter 26 (bounded quantification) has all the details of why generics are hard to add to languages if they also employ a construction of subtyping. In type theory, a feature by itself is easy to implement. It is in the interplay between different type features that things become hard to implement correctly. J.
|
| Re: [go-nuts] Re: What is so hard about adding generics? | Dave Cheney | 29/11/14 17:08 | How does an interface help me write a max function that only operates on numbers? Interfaces only specify behaviour, not data. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Tay | 29/11/14 17:22 | |
| Re: [go-nuts] Re: What is so hard about adding generics? | Matt Harden | 29/11/14 18:36 | If you don't allow generic interfaces, then the subtyping issue disappears. This doesn't mean generic types couldn't implement interfaces, however. --You received this message because you are subscribed to the Google Groups "golang-nuts" group. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Jsor | 29/11/14 21:55 | On Saturday, November 29, 2014 5:08:10 PM UTC-8, Dave Cheney wrote: I think in some way, what a lot of us are looking for is sort of the idea of type-safe interfaces and functions. This problem also kind of affects things like Heap to a degree. There's no good way to ensure at compile time that only MyType is pushed onto a heap, and only MyType is popped off a heap, because of the Interface thing. If I want to write a function that has a priority queue of Fooers, I can't enforce that, the user needs to pass in any old heap.Interface, and when I call heap.Pop I have to type switch myself every time. Okay, they could define another interface that wraps a heap.Interface, where MyHeap.Pop does the type assertion itself, but it's messy and involves frequent assertions. As you note, this is especially dicey with numeric routines. What if I have some function called SuperComplicatedMathFunction, that takes in two numbers, but the only basic operations it needs to work are addition or division? The typical Go paradigm suggests type AddDivider interface { Add(AddDivider) AddDivider Divide(AddDivider) AddDivider } func SuperComplicatedMathFunction(a,b AddDivider) But the problem here is that there's absolutely no way to ensure a and b can actually be added together. Both an int and a float64 are AddDividers, but only within the same type -- not across types. Trying to actually implement this leads to a mess of type switches. I did write a not-very-serious proposal for something that solves this particular problems here: https://gist.github.com/Jragonmiris/b69757366709d0fe884f But I think go generate fills close to the same void if I understand the tool right. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Tim Chirananthavat | 29/11/14 22:28 | This is probably the main reason to add generics. However, numeric routines are not the only routines that need generics. Custom data structures also need them. An example is designing a segment tree library for solving the generalized version of dynamic RMQ. You only need values that has some notion of "less than", but go can't do it with proper type safety. Note: By "segment tree", I mean this: http://www.topcoder.com/tc?d1=tutorials&d2=lowestCommonAncestor&module=Static#Segment_Trees |
| Re: [go-nuts] Re: What is so hard about adding generics? | Tim Chirananthavat | 29/11/14 22:50 | There are at least two ways to solve this with generics. 1. Use generic interfaces that allow some sort of self-reference. Create a new type or use an existing type that satisfies an interface. (Something like "type Comparable interface { (self T) IsLess(other T) bool; }" ). Pass values of that type to the functions/methods that manipulate the data structure. 2. Use generic functions. Create a function or use an existing function that compares two values. (Something like "type [T]CompareFunc func(T,T) bool".) Pass that function to the (second-order) function that creates the data structure. Personally, I feel that the latter approach is cleaner and simpler. Self-reference might lead to less boilerplate code if the corner cases can be properly dealt with, though. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Gyu-Ho Lee | 29/11/14 22:55 | Just question out of ignorance. What do you mean by `solving the generalized version of dynamic RMQ`? What do you mean by `go can't do it with proper type safety`? Why do we need generics to solve this problem? Thanks! |
| Re: [go-nuts] Re: What is so hard about adding generics? | Tay | 30/11/14 00:00 | I think you would can abstract the type switches away (you would have needed some sort of conversion anyway). I don't think you can be safe at compile time fully if you want genericity (well, or it is going to be costly) You can probably define the identity of data in the method set even though it is not necessarily optimal. The issue I see is bigger interfaces depending on someone's use case. But I think Jesper is right, at least in theory. The practice might be something else. Example of a Max function generalized to int64 and float64 : http://play.golang.org/p/rznK07-CY8 Trying that with a complex number should result in a runtime error. That's simply the result of needing genericity. But you can absolutely define order relations as methods. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Tim Chirananthavat | 30/11/14 01:52 | By "generalized", I mean doing it on any value with a well-defined connotation of "less than". By "proper type safety", I mean doing it without any type assertions. Anywhere. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Tim Chirananthavat | 30/11/14 02:00 | I think that the subtyping (aka interface embedding) issue can be easily be solved for generic interfaces. Example (in generic psudo-go): |
| Tay | 30/11/14 02:11 | <Ce message a été supprimé.> | |
| Re: [go-nuts] Re: What is so hard about adding generics? | Egon | 30/11/14 02:46 | This discussion doesn't seem to be going anywhere... You (huge generalization) are discussing only how to implement generics, but not the important points! IMHO the important points are: 1. How many problems does "generics" actually solve? 2. What are those problems? 3. How common are these problems in programs? (Do 1%, 5%, 10%, 25% of programs need it? What kinds of programs need it?) 4. Is "generics" the best solution to those problems? 5. What will the longer term effect will be on the generics? And when I mean problems, I mean actual problems, not "I want to implement this thing with generics", or "I can't implement LINQ"; those are just about implementing a solution and ignoring the problem. The more I look at these questions, the less I find reasons to introduce generics. + Egon |
| Re: [go-nuts] Re: What is so hard about adding generics? | Gyu-Ho Lee | 30/11/14 03:00 | Well said +1. Go team created Go to solve their problems in `Google` scale. If they needed generics, they should have implemented by now. Wonder what kind of real problems cannot be solved by not having generics. Recommend: http://stevebate.silvrback.com/go-is-boring |
| Re: [go-nuts] Re: What is so hard about adding generics? | Jsor | 30/11/14 03:45 | I don't really care about generics, my main issue is still type safety. Go is very strict about types, it doesn't even allow auto-addition of floats and ints. However, it also denies the ability to cleanly assure type matching. Often I don't care that a and b are floats, I care that a and b are merely the same basic numeric type. This has been very true in 3D linear algebra, geometry, and graphics packages for me, where aside from some hand-written SIMD code the vast majority of the code duplication could be trivially removed if I could use mostly the same code for 32-bit and 64-bit types. At the moment I use a Makefile that's mostly just cp and gofmt -r.
(Note that I'm not arguing that in theory deduplication of this sort of code can't be done without generics, I managed to write it generically at one point with a general Scalar type and large amounts of magic, but it benchmarked really poorly for performance-sensitive rendering-focused numeric code and had some really, really ugly typing and conversion shenanigans going on). I also worry about the type safety of heap. It seems far too easy to accidentally pollute a heap with the wrong type since it deals with interface{}s. Admittedly, this is almost dynamic typing, it's nothing I'm not used to with Python, but it's a bit odd for a language that normally has such strict, static typing. Sure, the language will end up panicking the second your container's Push is called due to trying to insert a bad type into a slice or whatever. But relegating basic container/collection type safety to a runtime panic concern seems contrary to Go's general safe, static typing philosophy to me. This is also more of an academic concern, every time I've used a heap it's been limited in scope to a single function/struct where you can be reasonably certain that you code will always push/pop the right types, but then that raises the question of why I'm doing a type assertion on every push and pop if I know the type a priori. Go generate is going to make this a bit easier once I get a better generator script written for my numeric code, but it's still a bit annoying. Is it important? Not really, it's a small annoyance, and I'd wager that in reality generics probably really affects <10% of developers meaningfully. Personally, I don't think Go should really add them, but I like posting in these discussions because I find theorycrafting a palatable model for them fun. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Jesper Louis Andersen | 30/11/14 07:05 | Come to think of it, I'm not even sure people mean the same thing when they say "generics". It is more likely that people have different opinions on what generics constitutes and what the goals of such a solution happens to be. What I am trying to say is that the interplay between features is complicated and there is no simple solution. The interplay I am trying to argue against is that if you allow generically varying data in the language, you will have to address that one can pass an interface type as a value and since interfaces define a subtyping lattice, then the touch-move rule of chess applies: any solution will be forced into handling interface values at some point or the other. And since interfaces obviously defines a subtyping lattice, your type soundness can only be addressed by adding something like bounded quantification[0] Personally, I'd much rather see a system closer to Haskell's type classes/families or something like StandardML/OCaml functors. Having done away with deep class hierarchies in Go already, it feels wrong to add another tool from the OO toolset that turns out to have failed in practice. Go's strength when considering its interfaces is the loosely coupled, implicitly maintained, compositional structure. The fact you don't have to declare/nominate a relationship before using it is a great help to programmers since it makes programmer interaction more on-demand. A good addition to the expressibility of the language must maintain this strength at all costs. And chances are generics in some form or the other destroys this property. In addition to the destruction of other good properties like fast compilation speeds, or good execution speed. [0] Of course, there is a chance I am totally wrong here. But the Go language does not enjoy the benefit of having a formal semantics, so it is hard to say exactly, formally, how interfaces operate. J.
|
| Re: [go-nuts] Re: What is so hard about adding generics? | Matt Harden | 30/11/14 07:26 | +Jesper Louis Andersen, I completely agree with you. Personally I think of Haskell's type classes as form of "generics" but the term is so overloaded that people end up talking past one another. Now, how could we add type classes to Go or extend interfaces to something more like type classes, and as +egon asked, what real problems would the proposal solve, and at what cost in terms of compile- or run-time speed and complexity? --You received this message because you are subscribed to the Google Groups "golang-nuts" group. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Nick Craig-Wood | 30/11/14 08:34 | On 30/11/14 11:45, Jeff Juozapaitis wrote:If you want a heap with a specific type then gotemplate + go generate will do that for you today. https://github.com/ncw/gotemplate and https://github.com/ncw/gotemplate/tree/master/heap -- Nick Craig-Wood <ni...@craig-wood.com> -- http://www.craig-wood.com/nick |
| Re: What is so hard about adding generics? | Haddock | 30/11/14 09:14 |
Just as a side note: Rust has templates, but doesn't have inheritance, either. |
| Re: [go-nuts] Re: What is so hard about adding generics? | akwillis | 30/11/14 09:18 | The problems are: 1. code reuse. Right now I am editing the type information for the value of a Set struct everytime I use it within a project that uses a different type. Basically I'm using the original like a template. That is no good. 2. Set theory. Anywhere I feel the builtin types(array, slice, map) are not flexible enough. 3. This issue is common among all my work. 4. Yes. Some class of generics would be useful. The problem is that every time this subject is broached it gets generalized into countless different models. The model I'm most interested about in regard to generic programming is type parameterization. And Yes, this would be the best solution, the only other solution would be to rewrite each package everytime I need to use a different type. Using the silly interface hack works but is very inefficient. 5. Code reuse. Set theory and efficient data types are my problems(it is my work) and right now the builtin types aren't enough. Using go generate as a preprocessor is a step in the right direction but I'd like a less commands on type of approach. |
| unk...@googlegroups.com | 30/11/14 09:34 | <Ce message a été supprimé.> | |
| Re: [go-nuts] Re: What is so hard about adding generics? | akwillis | 30/11/14 09:35 |
Just for starters, code reuse.
|
| Re: [go-nuts] Re: What is so hard about adding generics? | Nigel Vickers | 30/11/14 10:35 |
I think you should be called on this. Effective "code reuse" is possible. It requires an inordinate amount of shop discipline and rarely achieves the levels of adoption claimed. It is not bound to generics. It is mostly "application domain" specific. It is more of "Marketing Hype" than serious benefit.
|
| Re: [go-nuts] Re: What is so hard about adding generics? | Viktor Kojouharov | 30/11/14 14:57 | Imho the big problem here is that go doesn't support function overloading. If programmers were allowed to create different Max functions depending on their input (and why not output) arguments, some sort of `go generate` templating solution would be sufficient for anyone wanting to generalize a piece of code. And that's personally one of the few gripes I have with the language (whereas with generics, I really couldn't care less whether they exist or not). And since I don't really understand anything about compilers, can someone say what's the difficulty about implementing function overloading? > On Sat, Nov 29, 2014 at 9:23 AM, Dave Cheney <da...@cheney.net> wrote: |
| Re: [go-nuts] Re: What is so hard about adding generics? | Dave Cheney | 30/11/14 15:01 | If function overloading was added to the language, what would happen
to this piece of code. f := math.Max // just assume there is a max function for all numeric types fmt.Printf("%T", f) // what is the type of f ? And then we come to the problem of type aliasing x := math.Max(time.Second, Time.Millisecond) // oops, doesn't compile Function overloading _is_ important to be able to support generic functions, but without some notion of inheritance, it would be deeply flawed. > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/smT_0BhHfBs/unsubscribe. > To unsubscribe from this group and all its topics, send an email to |
| Re: [go-nuts] Re: What is so hard about adding generics? | Viktor Kojouharov | 30/11/14 15:22 | -- f := math.Max // just assume there is a max function for all numeric types That shouldn't compile, throwing some sort of ambiguity error. You'd have to specify the proper function via some sort of specialized syntax, such as: f := math.Max[...int][int] or f := math.Max[int, int][int] or in some crazy generic world: f := math.Max[T oneof int,int64,float32][T] But this in itself is not really an impassable obstacle for implementing overloading. Also, you currently already cannot assign the built-in functions (like the generic append) to variables (though I assume for different reasons). -- x := math.Max(time.Second, Time.Millisecond) // oops, doesn't compile This is already the case anyway, and unless go adds support for using any alias where applicable, this won't change (I have no idea why there is such a restriction in place). Still, this example illustrates a problem with implementing generics, not overloading. -- without some notion of inheritance, [function overloading] would be deeply flawed I'm genuinely curious as to why this would be the case in the context of go (as I've said, I'm not familiar with how languages are implemented). |
| Re: [go-nuts] Re: What is so hard about adding generics? | Dave Cheney | 30/11/14 15:37 | Viktor, I'm not having a go at you, or anyone in this thread
specifically, but I do ask that everyone who has proposed a solution look at what you are suggesting. Every single suggestion; covariant functions, operator overloading, interfaces that contain data, etc, do _more_ damage to the language in the form of restrictions on the previously logical and orthogonal feature set, than the potential gain from generics. Please, ask yourself, how much of the character of Go are you prepared to forgo to have templated types ? For me, I've already made my choice, I'll take Go as it is and use code generation, or just write the code N times (where N really is not unlimited despite what others would suggest) where necessary. Dave On Mon, Dec 1, 2014 at 10:22 AM, Viktor Kojouharov |
| Re: [go-nuts] Re: What is so hard about adding generics? | Dave Cheney | 30/11/14 16:16 | So now all the built in types have to implement methods ? This is just
getting worse and worse. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian Lance Taylor | 30/11/14 16:57 | On Fri, Nov 28, 2014 at 10:09 PM, Dave Cheney <da...@cheney.net> wrote:I think that one way to handle this would be to extend the structural typing of interfaces. We could say that a generic function Max can only be instantiated by types that support all the operations used in the body of the function. So if you write func Max(a, b T) T { if a > b { return a } return b } then Max can only be used with arguments whose types that support the < operator (integer, float, string types). In other words the permitted instantiating types are determined not only by the function signature, but also by the function body. Right, it can be anything like simple templated code generation. Either you introduce a meta-type system (unlikely) or you require that the instantiating type of Max be specified whenever it is used. In C++ syntax: max := Max<int> Ian |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian Lance Taylor | 30/11/14 17:15 | On Sun, Nov 30, 2014 at 4:57 PM, Ian Lance Taylor <ia...@golang.org> wrote:Sorry, s/can/can't/ . Ian |
| Re: [go-nuts] Re: What is so hard about adding generics? | Jsor | 30/11/14 18:50 | Function overloading _is_ important to be able to support generic My pseudo-"proposal" I linked earlier dealt with that, templated functions need to be explicitly created before use. So you'd have func Max(a,b T) T {
Now you use f := create(Max, int) bigger := f(1,2) Trying to do this with a struct, i.e. f := create(Max, MyStruct) Would yield the compile-time error file:line: cannot create function Max for type MyStruct file2:line2: invalid operation a>b (operator > not defined on struct) These can be disambiguated in the assembly as, just spitballing, ·Max·int ·Max·float32 And so on. In fact, I'd argue that a templated Max, i.e. f := Max, should yield "undefined: Max" (or perhaps something more specific like "template function Max is not assignable") If you want to keep it super orthogonal, you could even introduce something like "template func Max(a,b T) T". |
| Re: [go-nuts] Re: What is so hard about adding generics? | Matt Sherman | 30/11/14 19:20 | That's an intriguing approach. max := Max<int> How to handle it with multiple types in the func? I suppose Max<...argTypes, returnType>. Also, what about in the case of methods, or in the case of some parameters (or the return type) being concrete and some generic? |
| Re: [go-nuts] Re: What is so hard about adding generics? | Viktor Kojouharov | 01/12/14 00:26 | I just find the discussion very interesting. You have a lot more experience than me in go (a lot more, my first commit in my first piece of go code was in july of 2014), therefore i wouldn't even know about what kinds of damages the addition of function overloading would bring. The only real problem i thought of beforehand was assigning ambiguous functions to variables. And yes, the new syntax would cause problems, but imho it would not be severe, since it wouldn't present any compatibility faults. After all, currently there are no overloaded functions, so all old code will function as is (and of course, I could be very wrong on this assumption). So I really hope you stay active in this thread, as there's much to be learned. I personally enjoy using go, though I really find the omission of function overloading will hurt in the long run, especially now that code generation has been made easier. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Egon | 01/12/14 00:46 | On Sunday, 30 November 2014 19:18:05 UTC+2, akwillis wrote: That is not a good problem, but I can see you've added more detailed information.
I doubt that there can be a solution that is both fast and templated. The way I would implement a Set<byte> would be significantly different from Set<int>. There would be commonality for some types, but the overhead of running some code generation would be trivial.
That's a very vague problem, which means it cannot be properly analyzed. I.e. if I can't code a specific real world program that exhibits the problem I really can't understand the problem.
I doubt that getting both efficency and type parametrization is possible, at least in majority cases. I.e. I can see that working for somewhat similar types, e.g. uint32/int32 but going further than that not really. You might be somewhat faster than a interface{} based solution, but not as fast than a solution that takes the type other program specifics into account.
|
| Re: [go-nuts] Re: What is so hard about adding generics? | Egon | 01/12/14 00:54 |
Explicit naming of the type parameters: m := Map~{Key:int, Elem:string}{} a := math.Min~{T:int}(14, 51) |
| Re: [go-nuts] Re: What is so hard about adding generics? | Nick Craig-Wood | 01/12/14 02:35 | On 30/11/14 17:18, akwillis wrote:Gotemplate with go generate solves exactly this problem. It even has a set type template. Or you can use your own very easily. https://github.com/ncw/gotemplate https://github.com/ncw/gotemplate/tree/master/set |
| Re: [go-nuts] Re: What is so hard about adding generics? | Benjamin Measures | 01/12/14 02:48 | On Monday, 1 December 2014 00:57:51 UTC, Ian Lance Taylor wrote:I think that one way to handle this would be to extend the structural Don't we already get restrictions on what can be done "by the function body" with interfaces? func Max(a, b numeric.Interface) numeric.Interface { if a.LessThan(b) { return b } return a } Isn't then your suggestion more about operator overloading than "generics"? |
| Re: [go-nuts] Re: What is so hard about adding generics? | Tim Chirananthavat | 01/12/14 05:28 | type T1 int64 type T2 float64 //whatever methods here var x T1 = 1000 var y T2 = 2000.5 var z int8 := Max(x,y).(int8) //whoops Generics aren't that simple |
| Re: [go-nuts] Re: What is so hard about adding generics? | Jesper Louis Andersen | 01/12/14 05:44 | This looks very much like type classes in Haskell. However, you may have to nominate the relationship. For instance by declaring a type class Ord: type class Ord α { int Cmp(α, α) // Returns either -1, 0, or 1 } note how this almost looks like an interface, but requires you to specify values for which the type varies. And then in the max function assume we have a varying type α with the property that it is in the Ord type class: func (Ord α => Max(a, b α) α) { if Cmp(a, b) < 0 { return a } return b } func Cmp(a, b int) int { if a < b { return -1 } else if a > b { return 1 } return 0 } which can be implicitly instantiated. However, the usual problems tend to apply: you may have to solve some deep chains of type classes. However, on the other hand, it would open up the venue for implementing monads and monoids in Go ;) J.
|
| Re: [go-nuts] Re: What is so hard about adding generics? | Matt Sherman | 01/12/14 08:07 | The types package "flattens" the idea of type classes a bit. Instead of a hierarchy of types under type classes, types simple have attributes like Comparable and Ordered: https://godoc.org/golang.org/x/tools/go/types#BasicInfo |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian Lance Taylor | 01/12/14 08:50 | On Sun, Nov 30, 2014 at 7:20 PM, Matt Sherman <mwsh...@gmail.com> wrote:There are indeed many details to consider. This is really just the first level of detail. I tink it would depend on the syntax used to declare a generic method. Note that the syntax Max<int> can not work for Go, because, e.g., Abs<int>(-3) can not be parsed without a symbol table, which is not acceptable for Go. (Not that I want to get distracted by syntax, I was just commenting that I think generics can be implemented without worrying about subtyping.) Ian |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian Lance Taylor | 01/12/14 08:56 | The only operator overloading in my suggestion is the overloading that
is already present in the language. It does not introduce any additional overloading. Dave was saying that generics requires subtyping, with specific reference to predeclared types. I'm suggesting that there is a way to implement generics that does not require any subtyping. Your suggestion implies that the language must define interfaces for all the predeclared types. It also implies that people writing generic functions must only use methods, and may not use operators. Both ideas could be adopted but to me they look less than ideal. Ian |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian Lance Taylor | 01/12/14 08:59 | On Mon, Dec 1, 2014 at 5:28 AM, Theemathas ChirananhavatThe hypothetical Max function we've been discussing uses the same generic type for both parameters. Attempting to call it with arguments of different types must be a compile-time type error. I don't see that as a conceptual problem. In practice of course it would be essential to produce a good error message. Ian |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian Lance Taylor | 01/12/14 09:02 | On Mon, Dec 1, 2014 at 5:43 AM, Jesper Louis AndersenI'm fairly confident that if that is what generics requires, then they will never be implemented in Go. Go explicitly eschews this kind of type based programming. Ian |
| Re: [go-nuts] Re: What is so hard about adding generics? | atd...@gmail.com | 01/12/14 09:14 | And even for instance with the same generic interface, I believe such a type assertion is a compile-time error : int8 does not satisfy the interface. |
| Re: [go-nuts] Re: What is so hard about adding generics? | atd...@gmail.com | 01/12/14 09:17 | I don't think it needs to be that complicated. See Matt Sherman's post. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian | 01/12/14 09:26 | I'm not so sure that list of requirements is needed. If we apply some of your questions to Go, for instance, it's easy to conclude that Go is not needed! -- Generics solve problems across types; a quantifiable list of those problems is impossible to build.
-- Who knows? How is it possible to quantify such a number? (Besides extensive architectural analysis?)
-- Who knows? Sometimes they might be, sometimes they won't be.
-- Again, something that is difficult to quantify. Generics solve a set of problems; to quote Wikipedia's "Generics In Java article (http://en.wikipedia.org/wiki/Generics_in_Java): They allow "a type or method to operate on objects of various types while providing compile-time type safety." The implementation of any solution might or might not be better because of generics, a language might be more or less useful because of generics, but they exist in Java and C++ for a reason. That reason generally boils down to "so I don't have to keep writing code that does the same stuff over and over and over". The example that's used elsewhere in this thread is a trivial example, but get to any mildly complex example (web apps contain plenty of such instances), and generics start to look *very* appealing. Let the compiler worry about the differences and let the coder think about the interesting stuff, not implementing the same function over and over with copy-and-paste (or worse, retyping the same thing over and over...) Why should *I* have to rewrite code to solve the same problem for each data type when the compiler is so much better at such mundane and mind-numbing stuff? It strikes me that Go doesn't have generics not because they're not useful, but because the designers don't like them! Which is basically what they've said in a number of forums and in other threads about generics. /Ian |
| Re: [go-nuts] Re: What is so hard about adding generics? | Bakul Shah | 01/12/14 09:36 |
You can just use a type coercion: max := (func (int) int)(Max) This is more or less what the compiler would have to do to handle, e.g., Max(5, 6). > There are indeed many details to consider. This is really just the Indeed. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Benjamin Measures | 01/12/14 09:43 | On Monday, 1 December 2014 17:26:22 UTC, Ian wrote: References please. They've given very good reasons for not /yet/ having generic types in the language: We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. |
| Re: [go-nuts] Re: What is so hard about adding generics? | atd...@gmail.com | 01/12/14 09:58 | (Ian) designers don't like them (the solutions in the other languages) == (FAQ) design that gives value not yet found. I'd guess but can't speak for Ian. :) |
| Re: What is so hard about adding generics? | Nate Finch | 01/12/14 11:05 | I wish the pro-generics people on this list would respond to the multiple suggestions that they use one of the several existing code generators out there. This effectively gives you templates in Go just like they are implemented in several other languages, it's just a manual step instead of an automatic step. There's even the go generate command in 1.4 to make it a more standardized process. Thus, you can have your set of ints and your set of strings, and define a bunch of generic set theory logic. Personally, I do not want generics. I hope they never come to Go. I've spent almost my entire career writing software in languages with generics, and it inevitably makes the code more complicated and more difficult to understand for very minimal benefits in the real world. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Gustavo Niemeyer | 01/12/14 11:16 | While people can use go generate to implement custom sets, I don't think that was the goal for that helper, and I really hope it doesn't become a popular approach. One of the few things that would be worse than having a broken generics implementation in the language is having dozens of broken naive implementations of generics becoming popular within projects. On Mon Dec 01 2014 at 5:05:46 PM Nate Finch <nate....@gmail.com> wrote: -- |
| Re: [go-nuts] Re: What is so hard about adding generics? | Egon | 01/12/14 11:40 |
I know an exhaustive list is impossible. I simply want to see information that shows that adding generics is indeed the right way to do it and that there isn't a better way doing things. I know things aren't perfect, but we should be able to show that it's worth it.
My point here is that if the problems that generics solves are present only in 0.01% of programs, then is that a good argument for adding a feature? I'm really not asking for an exact number, just a vague idea of which kinds of programs exhibit those problems.
In a similar fashion "Is a surgery the best solution? Who knows, let's do one anyways."
I'm not asking exact quantities... simply reasoning that shows the good/bad effects of adding generics. We can make educated guesses based on other languages.
-- |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian | 01/12/14 12:26 | References? Although you wouldn't know it, I am familiar with that question; I've long considered the answer to be somewhat lacking. There's only one important sentence in that article you linked to, Benjamin, and it's not a good explanation. It's this one: "Generics are convenient but they come at a cost in complexity in the type system and run-time." If that isn't a rephrasing of my point, I'd like to know what it is! Here's my interpretation of that sentence: -- Generics provide some convenience for the coder. They're a good idea in that regard. [That's pretty much unarguable] -- They're complex [Hmm... Complex for whom? In what context are they complex? How is that complexity defined?] -- Go imposes some cultural and technical ideas, and complexity isn't one of them [Go's claim to simplicity is somewhat accurate for only one definition of "complexity!] -- Therefore, we don't like generics! [ergo...] I reckon that if the designers *liked* generics, they would have been implemented from the (ahem...) get-go. /Ian |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ugorji Nwoke | 01/12/14 12:33 | I believe most users on the group that are asking for generics just want a couple of fundamental features: 1. type-safe and performant containers: Gives type-safety guarantees by the compiler and performant runtime (without the overhead of interface conversions). 2. type-safe and performant algorithms: We can see where this feature could help in the following areas of the standard library: - sort package only provides implementations for int, string and float64. That leaves a large number of types unsupported (intXXX, uintXXX, float32, etc). (see sort.XXXSlice, sort.SearchXXX). - container/XXX: this library is not used much because it is not type-safe and is also consequently less performant because of interface conversions. - math.MaxXXX(...) where the library only supports a few types. - sync.Pool: works with interface{} because go doesn't have generics In my own codebase, I have had some uses of it: - SafeStore: This is a version of map[K]V suitable for concurrent use. Users can Get() and Put() without having to manage concurrent access themselves. I have it in a library, and every user of this library code currently auto-generates it for the types it uses. - codec library: I auto-generate 100's of implementations for a basic algorithm, because of lack of generics. This was the only way to improve the performance for known map types. It is inconvenient to expect users to always generate their implementations: - The user may not be the library author. The user now has to keep their generated code in sync with the primary code of record. - The library author must already have designed his code so that users can auto-generate against it. Go spec defines the following: - Identifier names must be digits, letters or _ - there is no operator overloading beyond that defined in the spec - there is no hierachy in types I don't believe that generics is an unsolvable problem within this constraints. Once a problem is defined, it can be solved. Go already strives to be a language with opinionated limits. A solution for generics in go which limits itself so the features are simple and in line with the spirit of go. I understand the sentiment of the go authors to not solve this problem until it is fully understood. I think we are close to that point now i.e. of fully understanding the issue after 5 years without it and after seeing where other languages have failedi n their implementations. |
| Re: What is so hard about adding generics? | atd...@gmail.com | 01/12/14 13:12 | Could add that most people forget about concurrency. C++ users probably know about the keyword "volatile" and its relative insufficiency. Go has to work on a variety of hardware platform with different memory models. Type safe Generics that are not template based is a harder problem than it may look. A template-like solution wouldn't work universally without sacrificing some performance for example. And performance it something that seems to matter to the Go users a whole lot too. Introducing any kind of generics should probably not change the Go ecosystem too wildly. User packages need to interoperate finely, just as they do nowadays. Wanting generics is fine but people should be aware, or at least think about the tradeoffs and the costs. Personally I have full confidence that the Go Authors and the Go team have not only our backs, but also their own which is even more comforting ! :)
|
| Re: [go-nuts] Re: What is so hard about adding generics? | Tim Chirananthavat | 01/12/14 17:08 | OK... Here is an improved version. Where is the error?
var val1 numeric.Interface = x var val2 numeric.Interface = y var val3 numeric.Interface = Max(val1,val2) //Does this produce an error/panic? var z T2 = val3.(T2) //What about this? //var z T1 = val3.(T1) If you don't do a type assertion, you would get a value of type "numeric.Interface", which is not very useful if you also have functions that accept only T1 or T2. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian Lance Taylor | 01/12/14 17:28 |
You're replying to me, so I think I've crossed sub threads somewhere. Just in case, let me say that I agree: adding an interface for all predeclared types is not sufficient for real generic functions. Ian > On Monday, December 1, 2014 11:59:33 PM UTC+7, Ian Lance Taylor wrote:> -- > You received this message because you are subscribed to the Google Groups "golang-nuts" group. > For more options, visit https://groups.google.com/d/optout. |
| Re: What is so hard about adding generics? | Tim Chirananthavat | 01/12/14 17:34 | Since that debate in the #go-nuts IRC a few days ago, I have realized that my idea of what "go generics" should be like (i.e. like haskell) is not complete. However, if you are satisfied with a certain level of "partially complete", people will say "Can't you support a little bit more?", and we go down that slippery slope to the complete complexity of haskell's type system. The reason is that haskell supports functional dependencies and type families, which are complex and not so easy to incorporate into go. One specific case that my "design" fails is supporting this: (psudo-go code start) type PromoteAdder interface {...} //whatever here type T1 int32 type T2 int64 //whatever methods here func PromoteAdd2(x PromoteAdder, y PromoteAdder) ? {...} //What is the return type? var x T1 = 1 var y T2 = 2 var a T1 = PromoteAdd2(x,x) var b T2 = PromoteAdd2(x,y)var c T2 = PromoteAdd2(y,x) var d T2 = PromoteAdd2(y,y)(psudo-go code end) In case you know haskell, this is how haskell supports this using functional dependencies: (haskell code start) import Data.Int class PromoteAddable a b c | a b -> c where promoteAdd :: a -> b -> c newtype T1 = T1 Int32 newtype T2 = T2 Int64 instance PromoteAddable T1 T1 T1 where promoteAdd (T1 x) (T1 y) = T1 ( x + y ) instance PromoteAddable T1 T2 T2 where promoteAdd (T1 x) (T2 y) = T2 ( fromIntegral x + y ) instance PromoteAddable T2 T1 T2 where promoteAdd (T2 x) (T1 y) = T2 ( x + fromIntegral y ) instance PromoteAddable T2 T2 T2 where promoteAdd (T2 x) (T2 y) = T2 ( x + y ) x = T1 1 y = T2 2 a :: T1 a = promoteAdd x x b :: T2 b = promoteAdd x y c :: T2 c = promoteAdd y x d :: T2 d = promoteAdd y y (haskell code end)
|
| Re: [go-nuts] Re: What is so hard about adding generics? | Lars Seipel | 01/12/14 18:27 | On Mon, Dec 01, 2014 at 09:26:21AM -0800, Ian wrote:That's exactly how it should be. After using Go for a considerable time now, I trust its designers' taste and can only encourage them to continue keeping out stuff they don't like. If I want C++ I know where to find it. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Thomas Bushnell, BSG | 01/12/14 18:51 | On Mon Dec 01 2014 at 12:26:14 PM Ian <ian.gr...@gmail.com> wrote: I'd argue it. There is not just "the coder"; there is the other coder who has to read and maintain, and it's not clear that providing convenience for the writer is worth arbitrary costs on other coders. Thomas |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian | 02/12/14 06:17 | Isn't that a "just" a specialized example of the perceived complexity of generics? That some implementations and uses of generics can be difficult to understand can't be a blanket criticism of the concept! After all, difficult to read code exists regardless of the language, the libraries and language facilities that are used and so on. The simple example that's been discussed in this thread can be perceived as complex because who knows which function is providing the required service? But isn't that little different to Go's interfaces, however? There's a semantic argument about the role of the reader versus the coder that could be made by the anally retentive, but that's actually irrelevant to your point. I can, however, maintain that the job of generics is to make life easier for the coder; whether that goal is actually realized is a different question! Any sufficiently complex solution can be either aided by careful use of generics, or harmed by it. And while Go imposes arguably "good" coding practices, a goal that's either Sisyphean or the pursuing of an idiot-proof solution depending on circumstances, badly written and/or convoluted code still happens. Generics (and Go's style demands) don't, and can't, hinder that! What generics in Go would do, however, is provide another tool for coders to implement *simple* solutions. None of that is relevant however, because at the end of the day, Go's team leaders (to be more specific) don't like generics and likely as not, won't implement them. /Ian |
| Re: [go-nuts] Re: What is so hard about adding generics? | Milan P. Stanic | 02/12/14 08:08 | On Tue, 2014-12-02 at 06:17, Ian wrote:
[...] > None of that is relevant however, because at the end of the day, Go's teamNot only Go team leaders don't like generics, but also most of the subscribers on this list and most of the developers who codes in Go for more than three months. N.B. That is my impression after following this list for about three years. [...] |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ugorji Nwoke | 02/12/14 10:20 | That's untrue. I have been on this list since the beginning. I want generics, but accept that it might not come soon. There are clear places where generics adds value (algorithms and containers). The Go Authors provided some type-safe containers to handle a large percentage of the uses of generic containers. However, any extensions to those (e.g. concurrency-safe containers) requires extra work. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian | 02/12/14 12:16 | I'm not saying many folk don't want generics in Go; I was merely noting that the leaders of the Go team seem to be united in disliking generics. I believe it swayed their decision-making, by weighing generic's "complexity" adversely. If they *liked* generics, it would be a part of the language, and people would accept the facility existed. They might not like the facility, but that would be a moot point if the facility existed. It doesn't, and a seemingly perpetual debate about them is the result. Personally, I do not expect generics to be supported in Go anytime soon. Because the Go managers don't like 'em! (Yep, it's circular.) If it were put to a vote, I wouldn't be surprised if it was almost 50-50, with the "no generics" voters ultimately prevailing.
|
| Re: [go-nuts] Re: What is so hard about adding generics? | Eric Johnson | 02/12/14 15:02 | Not a "leader" or "manager" of Go, and for the most part, I've come down on the side of not needing/wanting Generics. In my time, I've dealt with extremely complex Java generics, and complex C++ templates. I got good at them. Yes, they're complicated. When I picked up writing in Go, I expected that I would want generics. Then I started writing code, and discovered that I didn't need them. Once or twice, I've done sort operations, using the standard library, and cursed at the fact that I have to write a redundant function that returns the length of a slice. Since then, I've noticed a bunch of tools available for "generic-like" capabilities - based on generated code. Given the availability of those, I've had them in the back of my mind for when I might need to use them. And then I've not needed them. So I've come around to thinking about "generics" in a specific, concrete way - show me the use-case! And then show me how you cannot solve that use case with the existing tools, or how a proposed new solution is concretely better than one of the existing tools. Code generation just doesn't seem like a huge problem to me. Eric
|
| Re: [go-nuts] Re: What is so hard about adding generics? | Frank Schröder | 03/12/14 00:13 | I've come to the same conclusion. +1 Frank |
| Re: [go-nuts] Re: What is so hard about adding generics? | Pierre Durand | 03/12/14 01:22 | @Eric Johnson: +1 |
| Re: What is so hard about adding generics? | thwd | 03/12/14 04:24 | I don't understand your pseudo code but I do understand functional dependencies and haskell's type system. For the record: fundeps are not part of Haskell but a compiler extension; one that introduces new syntax and little added value (a determinant constraint on one type of a type class). This is clearly not something you'd see adopted in Go. Haskell's type system (not the turing-complete superset implemented by GHC) is a great example to follow and with some sane restrictions it shouldn't be hard to port to Go. All that said; the Go authors are no dummies and as a long-time gopher I am rather inclined to think that they _fundamentally_ don't want a strong/deep/functional type-system; even if there was one that worked better than what rsc describes on his blog. - Tom |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian | 03/12/14 06:21 | I think you missed my point? It's not whether *you* like generics or templates, my point is that the leadership of the Go team doesn't like and has (likely) never liked them and as a result weighed the negatives far more heavily than the positives! Like so many language facilities, generics can be implemented well, or shoddily; they can be used wisely or not. Sometimes facility "x" is essential, sometimes it's a nice to have; a facility can be a hinderance for one coder and a boon for another. But saying that you have discovered you don't need a facility is not the same as saying that the facility isn't needed! Before C++ templates, people worked around the problems that the templates solved. And now templates form a core part of the C++ toolset! Just as Java's Generics library has become an essential tool in the Java toolkit. Perhaps Go simply hasn't been employed to solve the sort of problems that led to the enthusiastic development of C++ templates and Java's Generics? Perhaps Go coders have come to accept and, in some cases, welcome the code duplication that a lack of generics requires? As you no doubt know, generics solve a problem; they wouldn't exist in other languages, otherwise. A few lines of duplication here and there is no big deal. A lot of lines of duplicated code to solve complex problems? That's a different kettle of fish! Go has an interesting (and somewhat limited and arbitrary) concept of "complexity"; the lack of generics is simply a part of that, for wont of a better word, "philosophy". Considering the "benevolent-ish dictator" model used for the governance of Go, they won't be a part of Go in the near, mid or (more than likely) long term, so discussion ultimately becomes pointless. /Ian |
| Re: [go-nuts] Re: What is so hard about adding generics? | Konstantin Khomoutov | 03/12/14 07:14 | On Wed, 3 Dec 2014 06:21:20 -0800 (PST)
Ian <ian.gr...@gmail.com> wrote: [...] > Go has an interesting (and somewhat limited and arbitrary) concept ofUh, please consider this: you appear to be a bit fixated on your own idea (repeated in this tread multiple times) that major Go devs are simply inclined in their reasoning to not include generics and that that's the chief reason this feature is not there and no work is being done to implement or even discuss it. The problem here is that this idea is just your very own perception of the reasons for Go not having generics, and it may be true but may be not, and most subscribers of this list appear to think it really is not. ;-) I'm not trying to disprove your idea, and I'm not putting forward my own ideas but what I'm trying advise you is to may be get a bit easier on believing your own imagination: what if Go devs indeed have purely technical reasons, as they (and others) have stated? The way to deal with the situation, as many have pointed out, is to put forward an elaborate techincal proposal and post a reference to it here for public examination. Elaborate is the key word: unfortunately, each discussion like the present one has the same scenario: micro-cases get being debated over with each "side" thinking they're debating over the whole concept instead. And this is where the real problem is. If you have a well thought-out document which (in your eyes) deals with every problem generics might bring into the language, such debates will be targeted and your proposal will either be refined in a useful way up to may be advancing it to an "official" proposal or critical flaws will be pointed out, and the proposal will fail the test. I mean, the main devs may be silent on cases like the present one precisely due to them only wanting to discuss concrete elaborate technical proposals and not because they outright reject even the very idea of discussing them. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Egon | 03/12/14 07:34 |
Which real-world problems are you having with regards to implementing something in Go?
|
| unk...@googlegroups.com | 03/12/14 08:49 | <Ce message a été supprimé.> | |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian | 03/12/14 08:49 | Oops... Nothing I can discuss at the moment, egon. Sorry. :-(
|
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian Lance Taylor | 03/12/14 08:55 | On Wed, Dec 3, 2014 at 6:21 AM, Ian <ian.gr...@gmail.com> wrote:As a member of the Go team for several years, I don't this this is accurate. I think it's fair to say that most of the Go team do not like C++ templates, in which one Turing complete language has been layered over another Turing complete language such that the two languages have completely different syntaxes, and programs in both languages are written in very different ways. C++ templates serve as a cautionary tale because the complex implementation has pervaded the entire standard library, causing C++ error messages to become a source of wonder and amazement. This is not a path that Go will ever follow. I think it's also fair to say that regardless of how one feels about Java generics, that approach can not be used in Go: it loses the type reflection information that is an essential aspect of Go programming, used in fundamental packages such as fmt. I've never heard anybody on the Go team say anything bad about C# generics, but unfortunately the implementation relies on C# using a JIT and on all non-primitive types being the same size, neither of which are true for Go. Languages like Haskell start from a very different place. It's hard to easily fit the complexity of the Haskell type system into a simpler language like Go. It's also true that most people writing large complex Go programs have not found a significant need for generics. So far it's been more like an irritating wart--the need to write three lines of boilerplate for each type to be sorted--rather than a major barrier to writing useful code. Go's interface types and nearly complete reflect package already permit one to write almost all desired type safe generic code, with the significant provisos that 1) the code is ugly; 2) the code is relatively slow; 3) the code is only type checked at run time, not compile time. So from the viewpoint of functionality generics in Go are not a fundamental reshaping of the language as they are for C++ and Java; they are an attempt to eliminate some real difficulties in what can already be done in the language. An acceptable generics proposal would do that without making the language significantly more complex or slow to compile. In other words, I think the benefit of generics in Go, while definitely real, is somewhat less than the benefit in C++ or Java. And the nature of Go, in particular the strong desire for ease of understanding Go code, perhaps makes the barrier to generics somewhat higher. In my thinking about generics in Go I've come to the view that even if they existed they would not be widely used. They would be used primarily for compile-time type-safe containers and algorithms. These are things that are written a small number of times by library writers and are then widely used. The language already contains examples of such things in the predeclared map and slice types, and the corresponding functions like copy, append, and delete. I think this is similar to how C++ templates are used in practice. Many people use std::vector and std::sort, and the syntax and the error messages are such that you are deeply aware that you are using templates. A much smaller number of people write std::vector and std::sort. Most of the templates defined in non-library C++ code would in Go naturally be implemented using interfaces. (I say this as somebody who wrote a C++ program, the gold linker, that actually does define and use templates in a fundamental way, for speed; while I still think it was the right decision, the reaction of most programmers to this code is dismay.) If you believe that, then it's worth pointing out that the core of the map and slice code in the Go runtime is not generic in the sense of using type polymorphism. It's generic in the sense that it looks at type reflection information to see how to move and compare type values. So we have proof by existence that it is acceptable to write "generic" code in Go by writing non-polymorphic code that uses type reflection information efficiently, and then to wrap that code in compile-time type-safe boilerplate (in the case of maps and slices this boiler plate is, of course, provided by the compiler). This then leads us back to the templating that many people have mentioned in this discussion. Perhaps we can figure out a way to define boilerplate code in a generic package that then implements the core of the package in the existing Go language, and automatically generate the boilerplate for clients of the package using "go generate". Ian (Lance Taylor) |
| Re: [go-nuts] Re: What is so hard about adding generics? | Anlhord Smithson | 03/12/14 09:24 |
but slices of any type are same size. its possible to implement generic collections of (slices). with some help from the language what do you think? |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian | 03/12/14 09:51 | I'm not sure why you say I seem to be fixated, Konstantin. In any conversation, points gets repeated either for emphasis or clarification. Without being defensive, I felt there was a need to emphasize a particular point. My claim is that there's an underlying non-technical reason why some facility hasn't been provided. (There, I did it again! :-) ) I haven't seen anything that contradicts that. Often, when seeking to affect change or challenge the status quo, it helps to understand why something is the way it is. Even though I *generally* like generics and templates, I'm not advocating for any particular change. I do find it very interesting that Go doesn't have generics and wondered why, so when this discussion popped up, I did some reading and reviewing. My conclusion was derived from deconstructing what I heard and saw in online videos and read on the web. Is it right? Is it wrong? Who knows? (Well...) It's a reasonable conjecture, and it was the only one that reasonably fit what I'd come across in my pondering. I'll try to provide concrete examples in the next couple of paragraphs. Yeah, I've been in many a technical discussion that required concrete instances and requirements, etc, to be discussed. I've been in micro-detail meetings, too. Some were important (deciding what type of washers to install in a data center fire suppressant system; I decided on silicone), some were a waste of time. I still cringe at the memory of one particular micro-detail meeting I was a reluctant part of, 20 odd years ago! We were discussing the legal definition of a word and no one could come up with a definitive definition that worked (I happily forget which one, but I remember it was vitally important to some contract). Painting that proverbial bike shed would be trivial in comparison... But the concrete can't exist until the overall goals and intentions have been figured out; this interesting. I couldn't make the decision on which washer the sprinklers would get until we, collectively, had agreed on the goals of the fire suppressant system; my decision led to a series of other decisions, some dictated by building codes, some by the architecture of the building and some by the tech we were installing. As you no doubt know, such discussions are a key to figuring out an architecture and/or a design. Intent can, and frequently does, matter. The concrete is meaningless without the foundation, and sometimes (often) figuring out the whys and wherefores includes how come such-and-such is a druthers and not a givens! At the moment, I'm extremely reluctant to tread the same ground as the fine and very clever folks who came up with C++ templates and Java's Generics library, to name but two implementations. Indeed, I *know* I couldn't even contemplate approaching their clarity and well crafted reasoning! Personally speaking, I like C++ templates because they're a powerful, well-thought out tool. Like many, I appreciate good tools. Go is a particularly fine tool, with some interesting and often irritating quirks, a carefully prescribed intent and, to my mind at least, an odd omission. That excision is interesting and I wondered why it existed. I don't agree that generics shouldn't be a part of Go; I clearly think they should! But arguing for the inclusion of generics on technical grounds when the reason they're not in the language is not at all technical is, I think you'd agree, a fool's errand. /Ian |
| Re: [go-nuts] Re: What is so hard about adding generics? | Benjamin Measures | 03/12/14 10:03 | On Wednesday, 3 December 2014 14:21:20 UTC, Ian wrote: Not all kitchens need an espresso machine. If you had a committee designing a kitchen, they'd probably try to get you an espresso machine. You might even use it once a month. The beans would be stale, the machine dirty and the coffee horrid. A Go kitchen would probably feature an AeroPress. Unfortunately, the generics equivalent hasn't been invented/discovered yet. |
| Re: [go-nuts] Re: What is so hard about adding generics? | atd...@gmail.com | 03/12/14 10:06 | You are free to fork Go and implement them :) And maybe we will follow you then... |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian Lance Taylor | 03/12/14 10:12 | On Wed, Dec 3, 2014 at 9:24 AM, <anl...@gmail.com> wrote: >> I've never heard anybody on the Go team say anything bad about C#I don't understand what you are proposing. I'll just say that a special purpose extension to the language for certain kinds of containers is very unlikely to happen. We already have slices and maps. Anything new added to the language should be at least as useful as those. We're not going to implement generics by adding a series of small language extensions. Ian |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian | 03/12/14 10:33 | Thanks for taking the time to provide a technical argument against generics in Go, Ian! Obviously I don't know anyone on the Go team, so all I had was their written words and what they said in videos. I'm not at all familiar with the type system of Haskell, and I don't know or deal with C# at all. I must confess to not liking, at all, code that repeats itself over and over. It is ugly, it's error-prone and it's simply shouldn't be needed in a modern language! I once had to debug a small monitoring app that brought down a database server; it had some repeated code of the "if this type of table, do this; if that type of table, do that" sort. A small mistake in one of those repeated functions was enough to send the app into an infinite loop! The issue was fixed by deleting the app and telling the admin not to do anything like that in the future. But that was in the early-90's; we're twenty years on and "oh, just write those same three (or "n" number of) lines, with variations, over and over" is still the prescribed solution? I get that with C, but with a new, modern language? Mind you, Go does shift the concept of complexity from the language to the coder. Writing the same "n" number of lines is introducing a level of complexity I've not seen since I was a furniture maker! There, accurate repetition of processes is valued. I'm not saying Go should embrace complexity (it shouldn't; that's what Java is for...) but surely there's a middle ground between adding a full-blown, Turing-complete generic system and Go's current approach of "It's not a problem to write those lines over and over"? That's simply an enthusiastic way of telling someone, "Yeah, you have to repeat that code for each data type..." And yeah, I wish Go's reflection system was better. But that's an entirely different discussion! Thanks, again. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian Lance Taylor | 03/12/14 10:58 | On Wed, Dec 3, 2014 at 10:33 AM, Ian <ian.gr...@gmail.com> wrote:Perhaps there is a middle ground. But it hasn't proved easy to find. Ian |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian | 03/12/14 11:03 | "Love it *all* or get the hell off our lawn!" is something I've seen quite frequently on this forum. It's a programming language, not a religion or political ideology.
|
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian | 03/12/14 11:04 | It has to be asked... Has anyone seriously looked? |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian Lance Taylor | 03/12/14 11:05 | On Wed, Dec 3, 2014 at 11:04 AM, Ian <ian.gr...@gmail.com> wrote:Yes. Ian > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. |
| Re: [go-nuts] Re: What is so hard about adding generics? | atd...@gmail.com | 03/12/14 11:10 | I kind of meant it. It is open sourced. You can contribute if you can/want to. At the very least you will happen to realize what are the technical difficulties by reading the source. And that will help you (in the general sense) figure out why the language is designed as it is. Good thing is that the code is quite readable and even the C portions are being converted to Go. By the way, if we had C++ template on top, the code would not be as readable. Even the C parts are not as readable ;) So, yeah.. that's what I meant. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Egon | 03/12/14 11:14 | Any similar domain that exhibits similar properties? Or can you convert this into some sort of game that exhibits similar real world properties? Although trying to figure out a better way in a different domain can be problematic.... + Egon |
| Re: [go-nuts] Re: What is so hard about adding generics? | Russel Winder | 03/12/14 11:18 | On Wed, 2014-12-03 at 11:03 -0800, Ian wrote:
[…] > It's a programming language, not a religion or political ideology.[…] Ah, I think I see the minor problem in your analysis. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russ...@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian | 03/12/14 11:40 | Yeah, I'm not a compiler writer... I don't have the time. I'm a guy trying to start his own business using the best tools he can figure out. Go is a good tool; it does what I need, but I reckon it could be better. And that weird omission *is* curious. (Not so mysterious now that Ian's explained it, however.) Do I want to contribute? Sure. Do I have the time? No. Do I think I'm enough of a team player to contribute meaningfully? Not a chance. Would I want to make such a contribution, spending the time to architect and develop a solution to such a complex problem, introducing such a change into the language, knowing it wouldn't be accepted? No, not really. Yeah, thanks for the advice on reading the source code... It's not like I didn't think of that. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian | 03/12/14 11:41 | Okay... Thanks. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian | 03/12/14 11:46 | Just to be sure, there's no immediate need on my part for something like generics. I just happen to think they're useful, and I do have a deep desire to not copy/paste/modify the same code over and over and over, but that seems to be an accepted practice in Go. (It has to be; there's really no other way of doing it!)
|
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian | 03/12/14 11:46 | :-) |
| Re: [go-nuts] Re: What is so hard about adding generics? | atd...@gmail.com | 03/12/14 11:53 | There is a code generation tool coming with the 1.4 release just in case you were not aware of this. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Anlhord Smithson | 03/12/14 12:01 |
|
| Re: [go-nuts] Re: What is so hard about adding generics? | atd...@gmail.com | 03/12/14 12:21 | You have to sell us the product... just don't drop it on me like that haha :) I will look at it though. I have a bunch of custom datastructures myself for which I'm currently writing tests. I don't really need generics for them though (I thought a lot about it but it doesn't always make sense in terms of access pattern and memory layout). I just need to replace some types here and there following my different use cases. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Anlhord Smithson | 03/12/14 12:32 | well its not really a product but I got a plan. i'm looking for various interface {} -> interface {} backends and converting them to int -> []byte as a warmup for plumbing. the []MYTYPE porcelain " layer" will be bolted on top of these basic primitives. this project doesn't address generic algorithms tho so thats issue is still open |
| Re: [go-nuts] Re: What is so hard about adding generics? | atd...@gmail.com | 03/12/14 12:44 | Well, if that's what you want to do, you could have a look at the gob package I guess but I'm not sure it is worth the overhead... |
| Re: [go-nuts] Re: What is so hard about adding generics? | DV | 03/12/14 13:12 | If you (or somebody else) can provide a "Go-with-generics" idea (or even better, working proof-of-concept) that:
then there's a good chance that proposal would be taken seriously. Saying "I-want-generics-but-I-don't-know-what-they-look-like-in-Go" is just not very productive and has been tried multiple times (dozens by now?) on these forums in the last 5-6 years. You're not the first to ask these questions, and you won't be the last. No hard feelings, it's just .... tiresome....?....to have to go through this exercise time and time again. Just do a search on this very forum on this subject, and after you're done reading *all* of that, see if you have the energy/desire to reply to the next person who asks this question, without sounding exhausted :-) |
| Re: [go-nuts] Re: What is so hard about adding generics? | andrey mirtchovski | 03/12/14 13:15 | further to your point, i'd venture a guess that this thread contains
more characters than all the copy-pasted, "boilerplate" in modern parlance, Go code that would've been eliminated using generics ever written so far. |
| Re: [go-nuts] Re: What is so hard about adding generics? | atd...@gmail.com | 03/12/14 13:21 | The FAQ is a good example of generic implementation but people don't seem to want to use this facility / understand it. :-D |
| Re: [go-nuts] Re: What is so hard about adding generics? | Egon | 04/12/14 01:44 | On Wednesday, 3 December 2014 21:46:16 UTC+2, Ian wrote: If you are currently constantly copy/pasting code around then there probably is a better solution and it doesn't have to be necessarily generics. I've been through the same phases; i.e. -> proposal for generics (e.g. https://groups.google.com/d/msg/golang-nuts/OQ6iwAHbAug/2LD8FgOPnj4J, https://groups.google.com/d/msg/golang-nuts/JThDpFJftCY/1MqzfeBjvT4J) -> trying to figure out actual use cases where it would be useful -> realizing that it doesn't come up that often. (e.g. https://groups.google.com/d/msg/golang-nuts/7xeflQp_IdA/J4YacRPf_04J) -> realizing that the answer for generics isn't as clear cut as it seems... Probably many others have gone through similar phases... To get the understanding why people are reluctant/not-so-fast to add generics - essentially pick some real-world cases (as close as possible) where you would like to use generics, but can't and it creates manual duplication - then let the community help you figure out a better/alternative way of achieving it. I know the feeling of powerless with Go, but all that power isn't really always necessary.... and quite often problems have other solutions. Basically, in my mind, before we can even decide whether generics is needed, we need a list of real-world problems/examples that it solves -- without that list we cannot properly analyze what would the best variant of "generics" be, how well it solves the intended problems... and then what are the problems associated with that version of "generics". This list is the first step to having a good conversation about practicality and usefulness of "generics". + Egon
|
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian | 04/12/14 06:06 | The copy/paste analogy was just that - an analogy. I've seen copy/paste code replacing generics, as I've described, but it was an analogy (that, interestingly enough, doesn't fall over the first moment it's closely examined). Yeah, there's seems to be a lot of "give me concrete examples" in the discussion about generics. It's an age-old silencing technique - demand an implementation that can be discussed, knowing that such a thing will likely never be delivered and that it can shot down if it should ever have the temerity to actually appear! Also, I'm not going to provide such an example because that focusses the discussion on a particular problem, not on the question of whether generics would be a positive or a negative for the Go language. At least two individuals have demanded proposals and working specifications, along with implementations that can be discussed. I've already said that undertaking such is not something I'm interested in pursuing. Mainly because it would distract from my primary goal of getting my business off the ground (the Go team get paid to develop Go; I don't get paid unless I deliver working products to clients), and why would anyone invest the time in proposing such a thing when the verdict firmly *against* including generics in Go has already been enthusiastically rendered? As I've already stated, I was interested in the discussion about *why* generics aren't in the language. Ian Lance Taylor provided a clear explanation why. (I still think my original claim stands, however.) In short, there are some problems for which generics provides the ideal solution. They wouldn't exist in other languages, otherwise. Can a solution to a particular problem be found if generics aren't available? Sure. Should the architect and/or coder have to jump through such hoops? Apparently, yes. I believe they would improve the language, making it more versatile, but I do seem to be the only one with that opinion. Considering that we now know generics will likely never be a part of Go (some will cheer at that!), and that Ian Lance Taylor's explanation provided a strong hint as to why, it's probably time to call this discussion over and use Ian's explanation as the definitive closing-down of the next generics discussion before it gets underway. Perhaps someone at Google could update the FAQ with Ian's explanation, which would probably help prevent however many future discussions about generics and Go? |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian | 04/12/14 06:10 | I reckon that if I did all that (I won't for reasons I've explained in another reply), the goal posts would be moved. It's an age-old silencing technique - provide us with a complete implementation we can critique! When we get to it, and if we like it, etc, etc, etc. The verdict is in, generics are likely never going to be a part of the Go language. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Egon | 04/12/14 08:02 | On Thursday, 4 December 2014 16:06:58 UTC+2, Ian wrote: IMHO, the goal of language features is to solve practical problems. If it doesn't solve problems then why have the feature? If it doesn't solve problems in the "best" way possible, then why implement the poorer solution instead of the better one?
And how can you measure/analyze whether adding generics would be a positive or a negative, when you don't have something to measure by? Nor without understanding which variant of "generics" is being added? btw. have you read any of the Go design documents (https://code.google.com/p/go-wiki/wiki/DesignDocuments). Language changes aren't added only because someone thinks they are great idea... they are argumented and every new feature has to fight for its existence.
Just because a feature exists in a language doesn't mean its a good idea. Take JavaScript as an example, a lot of initial decisions in it were made with haste and based on languages that were popular then.
If going through these hoops gives better, clearer and more robust code in general, then I would say yes. If it doesn't then maybe not... PS: I'm not saying that generics are useless... (just felt that I needed to clarify that)
|
| Re: [go-nuts] Re: What is so hard about adding generics? | Eric Johnson | 04/12/14 08:09 | Hi Ian,
On Thu, Dec 4, 2014 at 9:10 AM, Ian <ian.gr...@gmail.com> wrote: For the open source I've been involved in, what you describe sounds like how open source works in general. If you want to get stuff done, you can (a) file bugs, (b) identify clear use cases, (c) provide solutions (with test cases). Or offer to help other people doing those activities. If you started dropping emails on a Linux Kernel mailing list about how the kernel should adopt a microkernel architecture, and abandon the monolithic kernel approach, you might expect some of the same sort of responses. As in "OK - theoretically, might be better, but what's the use case you have in mind that isn't satisfied? Is there some other way to satisfy the problem?" "Can you provide an implementation that goes in the direction you suggest?" Linus would have a simple response - can you prove the value of the alternative?
That could be. Could be there is something that someone eventually comes up with that ends up being included for Go 2.0, or Go++, or some other future. Likely, when something that serves the use cases enabled by generics in other languages, it won't look the same in Go, because Go goes to great lengths to keep features orthogonal, in a way that other languages do not. That's what I like about the language. That's what I like about how I've seen the "generics" question tackled here. Your responses indicate you think this question is closed. All I've seen, though, is a lot of genuine engagement - but that engagement comes with hard questions. Eric |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian Lance Taylor | 04/12/14 08:56 | On Thu, Dec 4, 2014 at 6:06 AM, Ian <ian.gr...@gmail.com> wrote:It's true that this is an age-old silencing technique. It's also true that this is the way that the Go language was developed from the very start: not from first principles of language design, but from real experience writing actual programs. I agree that generics would bring benefits. The problem is that it would also bring costs. All proposed language features have benefits--if they didn't, nobody would propose them. The question is whether the benefits outweight the costs. Ian |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian | 04/12/14 13:16 | Personally speaking, I wouldn't go onto the Linux kernel list and propose it's time for tea! (I'm neither fond of Linux nor a fan of Torvald's.) Oh, believe me, I really do get the idea that a new feature or facility has to be "sold" to everyone, first. I've done the "sales job" enough (astonishingly, with some considerable success!) in corporate settings, more than occasionally implementing substantial changes! I'd like to see generics, especially function templates, in Go (as it happens, I've just had to write some code to deal with the same durned operation in int64, int32, int, etc!), but considering the animosity many in the Go community have toward them and my time and personal interest, I'm not about to begin actively advocating for them. To be totally blunt, it's not worth my time, considering the aggravation and the limited pay-off! Achieve the implementation of a feature the Go community universally seems to despise and the Go team has examined, rejected and doesn't want to spend time on? Yeah, I've got better things to do with my time and a few personally important goals to accomplish! |
| Re: [go-nuts] Re: What is so hard about adding generics? | Henrik Johansson | 04/12/14 13:33 | I get your frustration but I think this is the ways it must work. Forking is the way to change incompatibly (philosophically or technically) and that is an option. Really hard sure but still available. Like you said, it all boils down to time and effort even if there was a concrete suggestion on the table. Someone has to be willing to put in the hours regardless. I am fond of both Linux and Torvalds and even if that reception would be both skeptical and heated I imagine the same would happen in the Ruby community if asking for static typing. And remember, monoids are everywhere. Even in Go.
|
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian | 04/12/14 13:37 | As I've said, while I'd like to see a decent implementation of generics in Go, I'm not about to engage in any further advocacy for a facility you've already stated the Go team isn't very interested in! Go is a fine tool; it's probably one of the best server-oriented languages I've ever seen. (The range of languages I've used being somewhat limited in number...) It's oddly obvious that it's not built from first principles of language design! It also extolls an idiosyncratic philosophy about coding and data that doesn't always make sense, is occasionally debatable and definitely takes some getting used to. I stuck with it because it seemed better than the alternatives for what I want to accomplish; I was right in that decision, but, as my Mrs can testify, I do sometimes wonder about the wisdom of that decision! All that being said, I really do think someone at Google should spend the half hour it would take to rephrase your response and pop it into the FAQ to forestall this particular merry-go-round from spinning up, again. I think that would delight more than a few members of this forum. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian | 04/12/14 13:50 | Frustration? I'm not frustrated. Life's too damn short for something like that be frustrating! Heck, I'm not even disappointed. If anything, I'm perplexed why a modern language like Go didn't have generics from the beginning. I now know why, which isn't to say I agree with the reasoning, but at least I know why. There are some who think static typing in dynamic languages to be a reasonable idea. I understand Facebook is moving toward that model with their new variation on PHP. They have the resources to go it alone, and set the standards, just as Google has with Go. Sorry, I'm not about to lift the lid on Pandora's open source Box! |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian | 04/12/14 14:08 | I ended up answering questions all over the place... Yeah, I know how open source works. It's not that different to corporate life! But as I said elsewhere, in a small confusion over who made what statement (sorry about that!), I'm not about to lift any lid on Pandora's open source process box. As far as I can tell, the question about generics *is* closed. If someone did decide to spend the considerable amount of time it would take to produce all that is demanded, they'd have to persuade a community and the paid keepers of the Go torch at Google. The only way that would happen is if that someone absolutely had to have generics, was a master salesperson, had copious time to pursue and prosecute their case and definitely and absolutely needed to use the Go language. I think you'd agree, it would easier for such a person to simply develop the case for using another language. It's not going to make it into Go 2.0 because the development team isn't necessarily interested in pursuing it, and no doubt have other features they've deemed to be a priority. Additionally, the community is against the idea. Add it all up, and it's a dead issue. And, quite frankly, I don't have the time or inclination for the "hard" questions at the moment. Right now, I've got too many life-affecting questions to deal with and some goals that are more important to me, personally.
|
| Re: [go-nuts] Re: What is so hard about adding generics? | Tim Chirananthavat | 04/12/14 23:53 | Totally agreed that the FAQ needs more information about generics.
BTW I have just realized that the original question (Is the problem about a good generics spec or a good generics implementation?) wasn't quite properly answered yet. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian Lance Taylor | 05/12/14 08:23 | On Thu, Dec 4, 2014 at 11:53 PM, Theemathas ChirananhavatI just reread the FAQ entries on generics and it looks entirely accurate to me. I don't see any need for more information there. I think it would be fine if somebody wants to pull together a wiki page with more details. If you restate the question I'll provide my own answer. Ian |
| Re: [go-nuts] Re: What is so hard about adding generics? | akwillis | 05/12/14 20:27 | It scares them. The simplicity of golang is in its implementation- not its use. Ironic, considering golang is a systems language, and systems use libraries, yet I have to jump through hoops and use hacky tricks and third party tools to accomplish what is relatively easy in most other modern languages.
|
| Re: [go-nuts] Re: What is so hard about adding generics? | andrey mirtchovski | 05/12/14 20:30 | > yet I have to jump through hoops and use hacky tricks and thirdObjection: hearsay! |
| unk...@googlegroups.com | 06/12/14 01:59 | <Ce message a été supprimé.> | |
| Re: [go-nuts] Re: What is so hard about adding generics? | thwd | 06/12/14 03:21 | I'll be the first to admit that implementing generics in a language without screwing it up is a scary task.
Nobody wants to be "that guy that turned a perfectly good language into java 2.0". Of course it's scary. |
| unk...@googlegroups.com | 06/12/14 08:41 | <Ce message a été supprimé.> | |
| Re: [go-nuts] Re: What is so hard about adding generics? | akwillis | 06/12/14 08:44 | please explain what you don't like about how Type Parameterization is implemented in java. Its a language extension, so you don't have to use the feature if you don't want to, and its done at compile time through preprocessing, so there is no overhead at runtime.
|
| Re: [go-nuts] Re: What is so hard about adding generics? | Henrik Johansson | 06/12/14 09:14 | Oh man... There are so many things wrong. I admit it can be convenient to _type_ occasionally but still type erasure is just plain wrong at least how it is done in java.
|
| Re: [go-nuts] Re: What is so hard about adding generics? | akwillis | 06/12/14 09:59 | type erasure is an artifact of the design of the virtual machine. golang wouldn't need to suffer the same fate. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Henrik Johansson | 06/12/14 12:07 | Well, sure but the compiler does it. Why, because it is really, really hard to get this right. Odersky and the others have been forced to jump through some serious hoops in Scala as well. As for Haskell, well slower compiles are hard to find... |
| Re: What is so hard about adding generics? | Anlhord Smithson | 06/12/14 12:55 | golang generics status of the project. so we have the BigVal type. We have a nice collection manager. all users of the backend are planned to work via this manager. We have a simple binary tree (tree/treebuf) as a sample but it lacks more delete and insert operations. the iteration on it works. Delete range type operations are also planned. We started doing a b+ tree backed collection that allows just initialize and append. I think about how to best do a delete-range operation on it. The updated testsuite on it seems to work and performance is nice. what needs to be done is we need to discover out how to make the best primitive operations which would ideally be atomic, or at least allow as a solid foundation for the high level operations on trees / lists etc. especially insert operation and delete (range?) operation. ideally they will work with iteratosr. speaking of iterators there's currently Atter. Atter knows the key it points to and when the collection is updated he should move to the correct item again. Nexter is spawned from atter and knows just his current and next position and is used primarily in for style loops. When you delete stuff nexter should recover itself to a next valid unvisited item,skipping void nodes of course. Both atter and nexter implement ender which allows them to point to a special EOF. this is implemented by them pointing to the trunk node of the collection. trunk is always present and it simplifies algorithms. trunk doesn't contain a value. trunk has just a right pointer to the root of the tree and root's parent is obviously a trunk. so feel free to contribute to the project i work on it in my spare time only. making some detailed plan would be good so if there's anybody who thinks they knows how generic collections should behave especially deletion and insertion, feel free to share an ideas, write tests and benchmarks. pointers to already existing / previous efforts and existing "collections" that can be ported to this project's framework are welcome. when someone ports linked list and implements the nexter / atter /ender iterators, sane insert /delete/delete range operations that would be brilliant and if its even atomic / optionally thread safe and iterators can fix themselves after insert delete that would be epic On Saturday, November 29, 2014 4:21:06 AM UTC+1, Theemathas Chirananhavat wrote:
|
| Re: [go-nuts] Re: What is so hard about adding generics? | Tim Chirananthavat | 08/12/14 05:56 | Is the main problem about generics in Go a coherent specification, or an efficient implementation? |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian Lance Taylor | 08/12/14 08:14 | On Mon, Dec 8, 2014 at 5:56 AM, Theemathas ChirananhavatThe two questions are inseparable. It's not useful to discuss a specification without discussing the implied implementation. If generics were very easy to write but ran 100 times slower than copying the code, nobody would use them. Ian |
| Re: [go-nuts] Re: What is so hard about adding generics? | Tim Chirananthavat | 09/12/14 16:13 | In fact, I couldn't think of a single reasonable design of generics that couldn't be implemented as the compiler emulating copy-and-pasting. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian Lance Taylor | 09/12/14 17:10 | On Tue, Dec 9, 2014 at 4:13 PM, Theemathas ChirananhavatThe C# implementation is an interesting case. For primitive types it is essentially compiler cut-and-paste. For objects, however, the actual code is generated once. This works because in C# all non-primitive objects are the same size. Method lookup is by default done when the generic code is generated (you can change this by marking the object as dynamic) which leads to some subtle differences in method resolution in generic code between C++ and C#. Ian |
| Re: [go-nuts] Re: What is so hard about adding generics? | Tim Chirananthavat | 09/12/14 21:59 | But it can be implemented as copy and paste, right? I think that any reasonable generics design *can* be implemented as copy and paste. |
| Re: [go-nuts] Re: What is so hard about adding generics? | thwd | 09/12/14 23:13 | As long as type definitions are constant, yes. As soon as you have malleable types (i.e. they can be specialized at runtime) you need a JIT.
Also, some languages allow the definition of new types at runtime. And some meta-languages have type systems where types are homoiconic with the rest of the code -- you also need runtime code generation for that. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian Lance Taylor | 10/12/14 05:46 | On Tue, Dec 9, 2014 at 9:58 PM, Theemathas ChirananhavatYou would not get the same result as C#, because it would change when method lookup occurs. In fact, the same is true for C++, although it's harder to produce an example. I admit that it's very likely that any real code for which method lookup differs between the generic/template implementation and a copy/paste implementation is buggy, but still the languages specify method lookup as behaving in a certain way. Ian |
| Re: [go-nuts] Re: What is so hard about adding generics? | thwd | 10/12/14 05:48 | On Wed, Dec 10, 2014 at 2:13 PM, Nicholas Radford <nikra...@googlemail.com> wrote:
Yes, you are right, Go is compiled ahead of time and has a static type system.
Some counter-examples to this behavior can be found here: http://cs.stackexchange.com/a/1561 "Generics" is a broad word that covers a lot of aspects of a type-system which can all be implemented in various ways. Depending on design and implementation, static code generation (aka. compiler copy-pasta) may not be sufficient. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Dave Cheney | 10/12/14 05:52 | Is it necessary to continue to beat this horse ? I assure you that it is quite dead. |
| Re: [go-nuts] Re: What is so hard about adding generics? | Ian | 10/12/14 08:57 | I think people are curious, Dave. The implementation of generics in Go is a deceased equine, but no one's flogging that particular glue- and plaster*-bound old nag. (With all due apologies for the, ahem, unsympathetic flagellation of that particular metaphor... :-) ) Anyhoo, it is interesting to chat about, and if people know *why* Go will (in all likelihood) never have generics, then (I reckon) that's for the better of the community! I think folk are just curious to know why. It's perfectly reasonable, with such a common modern-language facility, to wonder why it's not there! Who knows, maybe someone will have that "Aha!" moment as a result of the discussion? It's not likely, but folk are still interested simply because Go also attracts people who are interested in computer languages for their own sake. So of course they'll be curious about the implementation details, fascinated with comparing different approaches to the same problem and interested in the reasoning behind some of those implementation details. But I suspect you've just succeeded in sending this particular discussion to a strangely equine heaven, regardless. /Ian *Old (pre 1920's) houses in the UK (at least) often have horsehair plaster on the walls. The stuff is as dreadful as it sounds. The very devil to drill through, too.
|
| Re: [go-nuts] Re: What is so hard about adding generics? | Matt Sherman | 10/12/14 12:37 | Agree, I've quite enjoyed this thread, as a discussion of what generics are and what the problem space looks like. I don't think this thread has actually been a feature-for-Go discussion (much). Pleasantly surprised, in other words. |