Re: [go-nuts] Re: I am not in favor of generics.
I moved reply to the separate thread. Subject: "Is "Craftsman's approach" proposal generic enough?" https://groups.google.com/d/msg/golang-nuts/FOGMEFlL04s/kGQ9mKSsCgAJ -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: I am not in favor of generics.
Not a problem! On Thursday, September 20, 2018 at 11:55:04 AM UTC-4, Michael Jones wrote: > > [Apologies to Dave Cheney, timely pushback for David Collier-Brown] > > David, I disagree and suggest your remark is not well considered. Three > replies, one per sentence. > Not a problem! Indeed, thanks for the response. > > *"Right now, this looks like the third draft of an academic project."* > Not to me. This reads like years of thought and discussion among qualified > researchers and skilled implementers. Not to boast unduly, but if you look > at the history of Ian, Robert, and Russ, you'll see intimate responsibility > not only in Go but in Gnu C/C++, Modula, and more. What I see in the > proposal is informed wisdom. This is engineering so there is always a > better way, but this may be the best that can be seen before implementation > and experience. > > I've indeed worked with generics in other languages, and always considered that Go, which says it doesn't have generics, has the best set. Mind you, the notation is opaque. It says "create me a bunch of X", for a couple of heavily-used meanings of "bunch". You have to read an article on how it does it to understand the what. My usage of generics over the years has tended to collapse from many types originally to just sequences and hash tables. I literally don't remember the last time I did anything more complex in C++ or Java. Maybe a table of sequences, for a library for Steam games. I don't mean it as an insult to the skills of the community, but I don't see it as an advance, but rather as another experiment *in search of *an advance. To restate your "there is always a better way, but this may be the best that can be seen before implementation and experience", I think it could be the best way before implementation and experience, but I really wish to see more implementations, inclusive of this one, as conscious experiments. And I should say that the title doesn't characterize my thoughts (;-)). I am in favor of generics, but I'm cautious in my enthisiasm. > *"It suffers badly by comparison to make(), the existing mechanism."* > Yes, inherently so. The existing mechanism uses magic in parsing and > implementation—details known in the compiler but not exposed in the Go > language generally, to make things as easy as possible. It is nice. But > from before the launch of Go users asked "how can I do such things > generally, in my code, and not by extending the language or the compiler." > The answer was "use interfaces now and we'll think about generics later." > Later is now and indeed exposing aspects of behind the scenes compiler > magic is more complicated, that's inherent. The decision to be made is how > powerful vs how complicated. > I find the idea of make to be a simple API, just like a library. You ask it for a map of structs indexed by an int, and it gives you one. The overloading of m = make(map[string]int) versus a = make([]int, 5) makes me wonder what's happening. That, IMHO, is something that needs a better notation, where different parameter lists have differentiable names. Using an old *butt-ugly* notation, I would like distinguishable forms like a:= []int.New(5) and m := [int]string.New() At that point, the opacity is the same as with an API: it says to create a slice of int of size 5, implemented on an array, or a map of strings indexed by int, implemented as a thing in itself. If I need more context, I read the code and/or the blogs. > "Can we see some more alternatives, please?" > They are legion. Existing generics approaches in various languages are > more than ideas, they are living examples of design, ecosystem, and > behavior. Several proposals have been offered by the Go team and > collaborators here. The Go 2 design site lists many specific comments and > alternatives. Extensive thoughts have been shared, with *responsa sunt, > novi in via*. > Yes, I agree. Perhaps "ex Africa semper aliquid novi*" *will be our saving grace, or as the cavalry says, "keep on hacking, Algy" (;-)) Limited objectives, tight control is never fun, but we have something surprisingly good with the magic make() incantation. I'd love to see something that's a single step more general and a bit less like formal magic. --dave > > Not a personal attack. Trying to inform these statements and encourage > review and consideration. > > Michael > > On Thu, Sep 20, 2018 at 5:04 AM David Collier-Brown > wrote: > >> Right now, this looks like the third draft of an academic project. It >> suffers badly by comparison to make(), the existing mechanism. >> >> Can we see some more alternatives, please? >> >> --dave >> >> -- >> 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
Re: [go-nuts] Re: I am not in favor of generics.
[Apologies to Dave Cheney, timely pushback for David Collier-Brown] David, I disagree and suggest your remark is not well considered. Three replies, one per sentence. *"Right now, this looks like the third draft of an academic project."* Not to me. This reads like years of thought and discussion among qualified researchers and skilled implementers. Not to boast unduly, but if you look at the history of Ian, Robert, and Russ, you'll see intimate responsibility not only in Go but in Gnu C/C++, Modula, and more. What I see in the proposal is informed wisdom. This is engineering so there is always a better way, but this may be the best that can be seen before implementation and experience. *"It suffers badly by comparison to make(), the existing mechanism."* Yes, inherently so. The existing mechanism uses magic in parsing and implementation—details known in the compiler but not exposed in the Go language generally, to make things as easy as possible. It is nice. But from before the launch of Go users asked "how can I do such things generally, in my code, and not by extending the language or the compiler." The answer was "use interfaces now and we'll think about generics later." Later is now and indeed exposing aspects of behind the scenes compiler magic is more complicated, that's inherent. The decision to be made is how powerful vs how complicated. "Can we see some more alternatives, please?" They are legion. Existing generics approaches in various languages are more than ideas, they are living examples of design, ecosystem, and behavior. Several proposals have been offered by the Go team and collaborators here. The Go 2 design site lists many specific comments and alternatives. Extensive thoughts have been shared, with *responsa sunt, novi in via*. Not a personal attack. Trying to inform these statements and encourage review and consideration. Michael On Thu, Sep 20, 2018 at 5:04 AM David Collier-Brown wrote: > Right now, this looks like the third draft of an academic project. It > suffers badly by comparison to make(), the existing mechanism. > > Can we see some more alternatives, please? > > --dave > > -- > 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+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- *Michael T. jonesmichael.jo...@gmail.com * -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: I am not in favor of generics.
Right now, this looks like the third draft of an academic project. It suffers badly by comparison to make(), the existing mechanism. Can we see some more alternatives, please? --dave -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: I am not in favor of generics.
Thank you to everyone who has contributed to this thread. It is time for everyone to take a break for 48 hours. After this time if you feel strongly that there is a point which you must continue to debate please do so, but be mindful that many words have already been spent in this thread and the points of view expressed are unlikely to change. Thank you Dave -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: I am not in favor of generics.
On Wed, 19 Sep 2018 09:32:39 -0500
Robert Engels wrote:
> This is not what I am referring to. I am stating that with N generics types
> in a method the developer needs to write NxN case methods. Not feasible.
Wrong. On two axis.
1. As stated in proposal, CGG has no "generic type" (generic data).
CGG stays entirely within comfort zone of the current Go type system.
No new things. CGG allows for readable generic **code** only.
Within CGG proposal you can **not** describe generic data using
blocks of more grained generic data; i.e. in c++/java's matrioshka style.
By design.
2. CGG generic code will operate "on types or part thereof".
Example Sum, in its most compact version
func (x type []K) Sum() (r type K) {
for type K range int64(), uint64(), float64(), complex128()
for _, v := range x {
r += v
}
return
}
operates on any member of **infinite** set of concrete types
that has base type of either: int8, int16, int32, int64, uint8,
uint16, uint32, uint64, float32, float64, complex64 or complex128.
The developer implementing generic solution needs to write
`for _, v := range x {;r+=v;};return;};` source.
Above source makes to object code that will run alike for
`type my1 int8` and `type my2 int64`. Possible that it will be
a single variant for "all signed integers".
( From the contract one can infer, that Sum as stated may have up to 4,
and **at most** 12 emitted variants. None of which written directly
by the developer. )
In the second version, one that is meant to act also on some outstanding
type, the specialization is the devoloper's to decide. She decided to make
it for something like big.Int /T = big.Int/? Hmm.. I only need Add, so make
it more generic. `(*K) Add(K, K)` constraint allows for an x being a member
of infinite set of concrete types that "have method Add" of given signature.
Big.Int just happens to be member of that set.
func (x type []K) Sum() (r type K) {
for type switch {
case K range int64(), uint64(), float64(), complex128():
for _, v := range x {
r += v
}
case K (*K) Add(K, K):
for _, v := range x {
r.Add(r,v)
}
break
}
return
}
CGG allows for specialized generic code. With "all types something that
allowed types have in common" occupying a single case.
Within other generic package, eg. webcommerce one, developer is free
to define and use other Sum - domain specific. Eg one that sums all
posible types of virtual "items" kind:
package "webo"
func (x type []K) Sum() (r int) {
for type K.Value = int()
for _, v := range x {
r += v.Value
}
return
}
this Sum will take as x any struct with Value field that happens
to be int based. So Ticket (s) of below can be webo.Summed too.
type Reward int8
type Ticket struct {
n string
Value Reward
}
--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: I am not in favor of generics.
There is a reason that Google has moved to Angular2 from AngularJS. As applications get larger you need more structure in order to maintain them. Implements is one of the ways to provide the needed structure. I know having structure goes against hacking. Try having a conversation in a room with speakers in a hundred languages. Not easy. Structure, consistency, common language. Staying explicating what something represents is going to be a better communication tool. Sent from my iPhone > On Sep 19, 2018, at 10:02 AM, Thomas Bushnell, BSG > wrote: > >> On Wed, Sep 19, 2018 at 4:04 PM robert engels wrote: >> >> The opinion that well, since there is no implements I can define my own >> interface, and pass some stdlib struct that I can’t control as an >> “implementor” is hogwash. Because you also don’t control this code, the API >> is free to change - breaking your code. This is why the “backwards >> implements” is a bad idea. > > I have experience in a millions-of-lines connected code base which uses > exactly the strategy that you say can't work. I can confirm that it does work > if you use it correctly. -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: I am not in favor of generics.
On Wed, Sep 19, 2018 at 4:04 PM robert engels wrote: > > The opinion that well, since there is no implements I can define my own > interface, and pass some stdlib struct that I can’t control as an > “implementor” is hogwash. Because you also don’t control this code, the API > is free to change - breaking your code. This is why the “backwards > implements” is a bad idea. > I have experience in a millions-of-lines connected code base which uses exactly the strategy that you say can't work. I can confirm that it does work if you use it correctly. -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: I am not in favor of generics.
That's a different case than one which "implements" addresses. You don't
need "implements" to address that problem, if you think it's a problem.
Adding "implements" doesn't help. I understand there are people who think
adding generics might help, but that's a different thing.
On Wed, Sep 19, 2018 at 4:04 PM robert engels wrote:
> That is not true. Often, due to lack of generics things are passed as
> interface{} or a sub interface, and then type checked/casted in the method.
> When you refactor you will get no warnings that X no longer meets the
> contract. You have no obvious way either by looking at the code to know
> which interfaces a developer needs (or wants it) to implement. Things will
> fail at runtime,
>
> People state this is a plus - yes it is - for small easily
> contained/understood systems. As the application grows larger, this is a
> real bottleneck to productivity.
>
> Having ‘implements’ does nothing to harm the productivity - not having it
> hurts.
>
> The opinion that well, since there is no implements I can define my own
> interface, and pass some stdlib struct that I can’t control as an
> “implementor” is hogwash. Because you also don’t control this code, the API
> is free to change - breaking your code. This is why the “backwards
> implements” is a bad idea.
>
> Having implements is the easiest to understand large systems - if you use
> interface based design, you can get a full mental picture of the system,
> then by looking at implementors you can determine the concrete options
> (performance, capabilities, etc.)
>
> Try working with any dynamic language that has duck typing - it is
> impossible to refactor. Don’t take my word for it, just read any of the
> thousands of blog posts covering it.
>
> Go is no different.
>
> Go was designed to replace scripting tools, and C tools (usually systems
> level). It was not designed for large enterprise applications, and that is
> why it falls down in many places. It doesn’t mean it isn’t GREAT for what
> it was designed to do, and better than Java in many (most) of these cases.
> Large enterprise apps, no way.
>
>
> On Sep 19, 2018, at 8:39 AM, Thomas Bushnell, BSG
> wrote:
>
> Huh? Type safety is still checked by the compiler. Implements does nothing
> except put a road-block in the way and prohibit you from making an
> interface that some other package happens to implement.
>
> On Wed, Sep 19, 2018 at 1:40 PM Robert Engels
> wrote:
>
>> Go not having implements is a big problem when refactoring large Go
>> systems especially because it doesn’t have generics - all type safety is
>> gone and you fly by the seat of your pants.
>>
>> On Sep 19, 2018, at 4:26 AM, Wojciech S. Czarnecki
>> wrote:
>>
>> >> On Tue, 18 Sep 2018 15:22:01 -0700 (PDT) mhhc...@gmail.com wrote:
>> >
>> > The **stated** goal for adding some kind of generics to Go is
>> > and always was "how to not repeat writing same code just for a type".
>> >
>> > Now above practical goal, in minds of many, somewhat morphed
>> > to "Yeah, lets have real true generics so we can write/reuse
>> > smart and clever code we once upon a time wrote for c++/java".
>> > "So we need a way of expressing generic data in terms of other
>> > generic data then use abstract alghoritm on that".
>> > (Yep, team's proposal use: "in terms of operations")
>> >
>> > It now poisons all the proposals I've seen with syntax that
>> > forces **user** of the code to **repeat** at the **call site**
>> > type identifier for the sake of "code instantiation".
>> >
>> > Why? I think that's a mark of "one proper way for doing generics" burnt
>> > on the popular mindset. As hard to overcome as notion that one needs
>> > 'implements/implementing' to use interfaces.
>> >
>> > Does Go2 should have "implements" keyword added too?
>> > `type mytype struct{...} : implements io.Writer, ..., ...`
>> >
>> > What?! "Compiler knows whether your type satisfies an interface"
>> >
>> > Yeah, and at the call site compiler **does know** the parameter
>> > type too. This is the CGG basis.
>> >
>> >
>> > 1. Find a way to write "some Go code" that is suitable for set of
>> > types that have "something" in common.
>> >
>> > 2. Find a way to describe the set via the "something common"
>> > that implementation for said set will use on objects of matching types.
>> >
>> > 3. It **MUST** read as Go: no instantiation at call site.
>> >
>> >
>> > On Tue, 18 Sep 2018 15:22:01 -0700 (PDT)
>> > mhhc...@gmail.com wrote:
>> >
>> >> I was referring to this code
>> >>
>> >> func (x type []K) Sum() (r type K) {
>> >> }
>> >>
>> >
>> >> I did not understand how "// For var x []AnyType. ANY. " relates to
>> >> previous code.
>> >
>> > Previous code example was specific to `big.Int` type. Next I gave
>> > a really generic usage example via the constraint that already is
>> > described in CGG proposal: "type with given method implemented".
>> >
>> > With that constraint func Sum can be called on _any_ type that has
>> > a method (*T) Add(T,T). And
[go-nuts] Re: I am not in favor of generics.
+1 Go doesn't need generics, in fact it goes against its philosophy and core values. Lack of generics was one of the reasons I moved to Go, I worked with Java since version 3, and I do believe that generics just made Java worse. Regards. понедельник, 17 сентября 2018 г., 19:04:26 UTC+3 пользователь jucie@zanthus.com.br написал: > > Go core team is working hard to bring generics to the language because > several people asked for it. With all due respect for those users and for > people working hard to make generics a reality, I feel that a greater > number of people would suffer after generics adoption. So, I feel compeled > to manifest my opinion: sorry guys, Go with generics will be worse than Go > without generics. > > The language strives for simplicity since its inception and that is what > attracted a large part of its user base. We must think about who we will > want to have in our community 10 years from now. Supporting generics would > please a minority to the detriment of a large number of potential users. > > Today Go is easy to learn and tools are easy to implement. Please keep it > that way. > > Thanks. > -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: I am not in favor of generics.
This is not what I am referring to. I am stating that with N generics types in a method the developer needs to write NxN case methods. Not feasible. Sent from my iPhone > On Sep 19, 2018, at 9:25 AM, Wojciech S. Czarnecki wrote: > > On Wed, 19 Sep 2018 06:52:09 -0500 > Robert Engels wrote: > >> Also, I did read what you wrote. I questioned “what happens when you have N >> different generic types in the call signature. The select type statement >> has N*N cases. “. You did not respond. > > The object code (i.e. ssa then machine) is instantiated **only** when its > **used** with given types set. > > If you really do call f.genpkg.(x) method on 200 different types for f, > each with 200 N typed vars x you will pollute symbol table **at compiling > time** (4 entries you will not see until you dump the table). > > But resulting object code will have at most as many variants as M > and N have different base types / for-type-cases at most. > > It further can be size-optimized by factoring out type-sized operations > reusing a given code chunk for more than one base/case. > > Hope this helps, > > -- > Wojciech S. Czarnecki > << ^oo^ >> OHIR-RIPE -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: I am not in favor of generics.
On Wed, 19 Sep 2018 06:52:09 -0500 Robert Engels wrote: > Also, I did read what you wrote. I questioned “what happens when you have N > different generic types in the call signature. The select type statement > has N*N cases. “. You did not respond. The object code (i.e. ssa then machine) is instantiated **only** when its **used** with given types set. If you really do call f.genpkg.(x) method on 200 different types for f, each with 200 N typed vars x you will pollute symbol table **at compiling time** (4 entries you will not see until you dump the table). But resulting object code will have at most as many variants as M and N have different base types / for-type-cases at most. It further can be size-optimized by factoring out type-sized operations reusing a given code chunk for more than one base/case. Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: I am not in favor of generics.
That is not true. Often, due to lack of generics things are passed as
interface{} or a sub interface, and then type checked/casted in the method.
When you refactor you will get no warnings that X no longer meets the contract.
You have no obvious way either by looking at the code to know which interfaces
a developer needs (or wants it) to implement. Things will fail at runtime,
People state this is a plus - yes it is - for small easily contained/understood
systems. As the application grows larger, this is a real bottleneck to
productivity.
Having ‘implements’ does nothing to harm the productivity - not having it hurts.
The opinion that well, since there is no implements I can define my own
interface, and pass some stdlib struct that I can’t control as an “implementor”
is hogwash. Because you also don’t control this code, the API is free to change
- breaking your code. This is why the “backwards implements” is a bad idea.
Having implements is the easiest to understand large systems - if you use
interface based design, you can get a full mental picture of the system, then
by looking at implementors you can determine the concrete options (performance,
capabilities, etc.)
Try working with any dynamic language that has duck typing - it is impossible
to refactor. Don’t take my word for it, just read any of the thousands of blog
posts covering it.
Go is no different.
Go was designed to replace scripting tools, and C tools (usually systems
level). It was not designed for large enterprise applications, and that is why
it falls down in many places. It doesn’t mean it isn’t GREAT for what it was
designed to do, and better than Java in many (most) of these cases. Large
enterprise apps, no way.
> On Sep 19, 2018, at 8:39 AM, Thomas Bushnell, BSG
> wrote:
>
> Huh? Type safety is still checked by the compiler. Implements does nothing
> except put a road-block in the way and prohibit you from making an interface
> that some other package happens to implement.
>
> On Wed, Sep 19, 2018 at 1:40 PM Robert Engels > wrote:
> Go not having implements is a big problem when refactoring large Go systems
> especially because it doesn’t have generics - all type safety is gone and you
> fly by the seat of your pants.
>
> On Sep 19, 2018, at 4:26 AM, Wojciech S. Czarnecki > wrote:
>
> >> On Tue, 18 Sep 2018 15:22:01 -0700 (PDT) mhhc...@gmail.com
> >> wrote:
> >
> > The **stated** goal for adding some kind of generics to Go is
> > and always was "how to not repeat writing same code just for a type".
> >
> > Now above practical goal, in minds of many, somewhat morphed
> > to "Yeah, lets have real true generics so we can write/reuse
> > smart and clever code we once upon a time wrote for c++/java".
> > "So we need a way of expressing generic data in terms of other
> > generic data then use abstract alghoritm on that".
> > (Yep, team's proposal use: "in terms of operations")
> >
> > It now poisons all the proposals I've seen with syntax that
> > forces **user** of the code to **repeat** at the **call site**
> > type identifier for the sake of "code instantiation".
> >
> > Why? I think that's a mark of "one proper way for doing generics" burnt
> > on the popular mindset. As hard to overcome as notion that one needs
> > 'implements/implementing' to use interfaces.
> >
> > Does Go2 should have "implements" keyword added too?
> > `type mytype struct{...} : implements io.Writer, ..., ...`
> >
> > What?! "Compiler knows whether your type satisfies an interface"
> >
> > Yeah, and at the call site compiler **does know** the parameter
> > type too. This is the CGG basis.
> >
> >
> > 1. Find a way to write "some Go code" that is suitable for set of
> > types that have "something" in common.
> >
> > 2. Find a way to describe the set via the "something common"
> > that implementation for said set will use on objects of matching types.
> >
> > 3. It **MUST** read as Go: no instantiation at call site.
> >
> >
> > On Tue, 18 Sep 2018 15:22:01 -0700 (PDT)
> > mhhc...@gmail.com wrote:
> >
> >> I was referring to this code
> >>
> >> func (x type []K) Sum() (r type K) {
> >> }
> >>
> >
> >> I did not understand how "// For var x []AnyType. ANY. " relates to
> >> previous code.
> >
> > Previous code example was specific to `big.Int` type. Next I gave
> > a really generic usage example via the constraint that already is
> > described in CGG proposal: "type with given method implemented".
> >
> > With that constraint func Sum can be called on _any_ type that has
> > a method (*T) Add(T,T). And someone writing new code needs not to
> > change generic lib (as imputed), but she needs to provide for her
> > non-numeric or peculiar type a method (*T) Add(T,T). Then Sum works.
> >
> >> for your question about the rune, i guess it d be like this
> > [...]
> >> Consider Z,K as virtual types to be
Re: [go-nuts] Re: I am not in favor of generics.
Huh? Type safety is still checked by the compiler. Implements does nothing
except put a road-block in the way and prohibit you from making an
interface that some other package happens to implement.
On Wed, Sep 19, 2018 at 1:40 PM Robert Engels wrote:
> Go not having implements is a big problem when refactoring large Go
> systems especially because it doesn’t have generics - all type safety is
> gone and you fly by the seat of your pants.
>
> On Sep 19, 2018, at 4:26 AM, Wojciech S. Czarnecki
> wrote:
>
> >> On Tue, 18 Sep 2018 15:22:01 -0700 (PDT) mhhc...@gmail.com wrote:
> >
> > The **stated** goal for adding some kind of generics to Go is
> > and always was "how to not repeat writing same code just for a type".
> >
> > Now above practical goal, in minds of many, somewhat morphed
> > to "Yeah, lets have real true generics so we can write/reuse
> > smart and clever code we once upon a time wrote for c++/java".
> > "So we need a way of expressing generic data in terms of other
> > generic data then use abstract alghoritm on that".
> > (Yep, team's proposal use: "in terms of operations")
> >
> > It now poisons all the proposals I've seen with syntax that
> > forces **user** of the code to **repeat** at the **call site**
> > type identifier for the sake of "code instantiation".
> >
> > Why? I think that's a mark of "one proper way for doing generics" burnt
> > on the popular mindset. As hard to overcome as notion that one needs
> > 'implements/implementing' to use interfaces.
> >
> > Does Go2 should have "implements" keyword added too?
> > `type mytype struct{...} : implements io.Writer, ..., ...`
> >
> > What?! "Compiler knows whether your type satisfies an interface"
> >
> > Yeah, and at the call site compiler **does know** the parameter
> > type too. This is the CGG basis.
> >
> >
> > 1. Find a way to write "some Go code" that is suitable for set of
> > types that have "something" in common.
> >
> > 2. Find a way to describe the set via the "something common"
> > that implementation for said set will use on objects of matching types.
> >
> > 3. It **MUST** read as Go: no instantiation at call site.
> >
> >
> > On Tue, 18 Sep 2018 15:22:01 -0700 (PDT)
> > mhhc...@gmail.com wrote:
> >
> >> I was referring to this code
> >>
> >> func (x type []K) Sum() (r type K) {
> >> }
> >>
> >
> >> I did not understand how "// For var x []AnyType. ANY. " relates to
> >> previous code.
> >
> > Previous code example was specific to `big.Int` type. Next I gave
> > a really generic usage example via the constraint that already is
> > described in CGG proposal: "type with given method implemented".
> >
> > With that constraint func Sum can be called on _any_ type that has
> > a method (*T) Add(T,T). And someone writing new code needs not to
> > change generic lib (as imputed), but she needs to provide for her
> > non-numeric or peculiar type a method (*T) Add(T,T). Then Sum works.
> >
> >> for your question about the rune, i guess it d be like this
> > [...]
> >> Consider Z,K as virtual types to be inferred from the call site.
> > Progress! As to inferred :)
> >
> > But I wanted return to be a string with sum of runes from all
> > input strings :) Leave it.
> >
> > In CGG such specialization takes place in a single to find and simple
> > to **read** 'case' code. The proposal's example Sum already has a single
> > piece of code that will be **reused** for all numerical types that user
> > **might** declare off builtin. With only two for type cases CGG's generic
> > Sum spans all types with numerical base and all types that provide their
> own
> > "me plus operator". With one case more it allows for set of types that
> have
> > "plus me operator". Code that can and will run for multitude of user
> types.
> >
> > Yet I still hear stubborn "not reusable!, not reusable! not generic!".
> >
> >> In regards to Russ Cox proposal this code is missing
> >> their explicitly declared contracts and the function instances
> declaration.
> >> On the other hand, this is so much more readable *to me*.
> >
> > The "real true generics" proposals are readable to people who took the
> > time and the training to accommodate to such List>
> > syntactical mess. But it is **against** Go philosophy of "readability
> first".
> > It excludes the legion who finds mental instantiations cumbersome at
> > reading time. It shifts their thought from "what this will do" to "in
> what
> > shape it will be".
> >
> >
> >> maybe it looks likes c++, i did not think it was a concern
> >> as long as it respected desired behaviors of good error reporting,
> >
> > It IS a MAIN concern. In fact it is a concern that the Go
> > team explicitly stated as a reason why Go1 is generics free.
> >
> >> good readability,
> > It has **no** readability for all but c++/java conditioned
> > and is an inexhaustible source of confusion in other languages
> >
> >> ease of usage.
> > leading to ubiquitous C in java/c++ application of generic libs.
> >
> >> speed of compilation,
> >
[go-nuts] Re: I am not in favor of generics.
Anyone who doesn't want some form of generics is in favor of a bad status
quo. Now I'll be fine without user defined generics if Go provided a dozens
of built-in compile time safe generic data structures like trees, sets,
tuples, ordered maps, weakmaps perhaps WITH a complete set of methods like
map/reduce/filter/... it would be a good compromise.
I'd be fine, if generics could only be functions as well and not structs
with generic methods.
But the whole, "just use interface {}" gimmick in a statically typed
language? NO.
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: I am not in favor of generics.
Also, I did read what you wrote. I questioned “what happens when you have N
different generic types in the call signature. The select type statement has
N*N cases. “. You did not respond.
On Sep 19, 2018, at 4:26 AM, Wojciech S. Czarnecki wrote:
>> On Tue, 18 Sep 2018 15:22:01 -0700 (PDT) mhhc...@gmail.com wrote:
>
> The **stated** goal for adding some kind of generics to Go is
> and always was "how to not repeat writing same code just for a type".
>
> Now above practical goal, in minds of many, somewhat morphed
> to "Yeah, lets have real true generics so we can write/reuse
> smart and clever code we once upon a time wrote for c++/java".
> "So we need a way of expressing generic data in terms of other
> generic data then use abstract alghoritm on that".
> (Yep, team's proposal use: "in terms of operations")
>
> It now poisons all the proposals I've seen with syntax that
> forces **user** of the code to **repeat** at the **call site**
> type identifier for the sake of "code instantiation".
>
> Why? I think that's a mark of "one proper way for doing generics" burnt
> on the popular mindset. As hard to overcome as notion that one needs
> 'implements/implementing' to use interfaces.
>
> Does Go2 should have "implements" keyword added too?
> `type mytype struct{...} : implements io.Writer, ..., ...`
>
> What?! "Compiler knows whether your type satisfies an interface"
>
> Yeah, and at the call site compiler **does know** the parameter
> type too. This is the CGG basis.
>
>
> 1. Find a way to write "some Go code" that is suitable for set of
> types that have "something" in common.
>
> 2. Find a way to describe the set via the "something common"
> that implementation for said set will use on objects of matching types.
>
> 3. It **MUST** read as Go: no instantiation at call site.
>
>
> On Tue, 18 Sep 2018 15:22:01 -0700 (PDT)
> mhhc...@gmail.com wrote:
>
>> I was referring to this code
>>
>> func (x type []K) Sum() (r type K) {
>> }
>>
>
>> I did not understand how "// For var x []AnyType. ANY. " relates to
>> previous code.
>
> Previous code example was specific to `big.Int` type. Next I gave
> a really generic usage example via the constraint that already is
> described in CGG proposal: "type with given method implemented".
>
> With that constraint func Sum can be called on _any_ type that has
> a method (*T) Add(T,T). And someone writing new code needs not to
> change generic lib (as imputed), but she needs to provide for her
> non-numeric or peculiar type a method (*T) Add(T,T). Then Sum works.
>
>> for your question about the rune, i guess it d be like this
> [...]
>> Consider Z,K as virtual types to be inferred from the call site.
> Progress! As to inferred :)
>
> But I wanted return to be a string with sum of runes from all
> input strings :) Leave it.
>
> In CGG such specialization takes place in a single to find and simple
> to **read** 'case' code. The proposal's example Sum already has a single
> piece of code that will be **reused** for all numerical types that user
> **might** declare off builtin. With only two for type cases CGG's generic
> Sum spans all types with numerical base and all types that provide their own
> "me plus operator". With one case more it allows for set of types that have
> "plus me operator". Code that can and will run for multitude of user types.
>
> Yet I still hear stubborn "not reusable!, not reusable! not generic!".
>
>> In regards to Russ Cox proposal this code is missing
>> their explicitly declared contracts and the function instances declaration.
>> On the other hand, this is so much more readable *to me*.
>
> The "real true generics" proposals are readable to people who took the
> time and the training to accommodate to such List>
> syntactical mess. But it is **against** Go philosophy of "readability first".
> It excludes the legion who finds mental instantiations cumbersome at
> reading time. It shifts their thought from "what this will do" to "in what
> shape it will be".
>
>
>> maybe it looks likes c++, i did not think it was a concern
>> as long as it respected desired behaviors of good error reporting,
>
> It IS a MAIN concern. In fact it is a concern that the Go
> team explicitly stated as a reason why Go1 is generics free.
>
>> good readability,
> It has **no** readability for all but c++/java conditioned
> and is an inexhaustible source of confusion in other languages
>
>> ease of usage.
> leading to ubiquitous C in java/c++ application of generic libs.
>
>> speed of compilation,
> [I assume it was not about c++ compiling]
>
> With CGG a single significant change to current gc parsing will
> be in marking 'func' node so parser could swap the subtree when
> it will see 'for type' while in declaration body.
>
> The only bigger chunk of new code in gc will be for contract
> parsing and matching. Everything else needed for fast CGG
> implementation already is working in the current gc.
>
> [ c++ and like
Re: [go-nuts] Re: I am not in favor of generics.
Go not having implements is a big problem when refactoring large Go systems
especially because it doesn’t have generics - all type safety is gone and you
fly by the seat of your pants.
On Sep 19, 2018, at 4:26 AM, Wojciech S. Czarnecki wrote:
>> On Tue, 18 Sep 2018 15:22:01 -0700 (PDT) mhhc...@gmail.com wrote:
>
> The **stated** goal for adding some kind of generics to Go is
> and always was "how to not repeat writing same code just for a type".
>
> Now above practical goal, in minds of many, somewhat morphed
> to "Yeah, lets have real true generics so we can write/reuse
> smart and clever code we once upon a time wrote for c++/java".
> "So we need a way of expressing generic data in terms of other
> generic data then use abstract alghoritm on that".
> (Yep, team's proposal use: "in terms of operations")
>
> It now poisons all the proposals I've seen with syntax that
> forces **user** of the code to **repeat** at the **call site**
> type identifier for the sake of "code instantiation".
>
> Why? I think that's a mark of "one proper way for doing generics" burnt
> on the popular mindset. As hard to overcome as notion that one needs
> 'implements/implementing' to use interfaces.
>
> Does Go2 should have "implements" keyword added too?
> `type mytype struct{...} : implements io.Writer, ..., ...`
>
> What?! "Compiler knows whether your type satisfies an interface"
>
> Yeah, and at the call site compiler **does know** the parameter
> type too. This is the CGG basis.
>
>
> 1. Find a way to write "some Go code" that is suitable for set of
> types that have "something" in common.
>
> 2. Find a way to describe the set via the "something common"
> that implementation for said set will use on objects of matching types.
>
> 3. It **MUST** read as Go: no instantiation at call site.
>
>
> On Tue, 18 Sep 2018 15:22:01 -0700 (PDT)
> mhhc...@gmail.com wrote:
>
>> I was referring to this code
>>
>> func (x type []K) Sum() (r type K) {
>> }
>>
>
>> I did not understand how "// For var x []AnyType. ANY. " relates to
>> previous code.
>
> Previous code example was specific to `big.Int` type. Next I gave
> a really generic usage example via the constraint that already is
> described in CGG proposal: "type with given method implemented".
>
> With that constraint func Sum can be called on _any_ type that has
> a method (*T) Add(T,T). And someone writing new code needs not to
> change generic lib (as imputed), but she needs to provide for her
> non-numeric or peculiar type a method (*T) Add(T,T). Then Sum works.
>
>> for your question about the rune, i guess it d be like this
> [...]
>> Consider Z,K as virtual types to be inferred from the call site.
> Progress! As to inferred :)
>
> But I wanted return to be a string with sum of runes from all
> input strings :) Leave it.
>
> In CGG such specialization takes place in a single to find and simple
> to **read** 'case' code. The proposal's example Sum already has a single
> piece of code that will be **reused** for all numerical types that user
> **might** declare off builtin. With only two for type cases CGG's generic
> Sum spans all types with numerical base and all types that provide their own
> "me plus operator". With one case more it allows for set of types that have
> "plus me operator". Code that can and will run for multitude of user types.
>
> Yet I still hear stubborn "not reusable!, not reusable! not generic!".
>
>> In regards to Russ Cox proposal this code is missing
>> their explicitly declared contracts and the function instances declaration.
>> On the other hand, this is so much more readable *to me*.
>
> The "real true generics" proposals are readable to people who took the
> time and the training to accommodate to such List>
> syntactical mess. But it is **against** Go philosophy of "readability first".
> It excludes the legion who finds mental instantiations cumbersome at
> reading time. It shifts their thought from "what this will do" to "in what
> shape it will be".
>
>
>> maybe it looks likes c++, i did not think it was a concern
>> as long as it respected desired behaviors of good error reporting,
>
> It IS a MAIN concern. In fact it is a concern that the Go
> team explicitly stated as a reason why Go1 is generics free.
>
>> good readability,
> It has **no** readability for all but c++/java conditioned
> and is an inexhaustible source of confusion in other languages
>
>> ease of usage.
> leading to ubiquitous C in java/c++ application of generic libs.
>
>> speed of compilation,
> [I assume it was not about c++ compiling]
>
> With CGG a single significant change to current gc parsing will
> be in marking 'func' node so parser could swap the subtree when
> it will see 'for type' while in declaration body.
>
> The only bigger chunk of new code in gc will be for contract
> parsing and matching. Everything else needed for fast CGG
> implementation already is working in the current gc.
>
> [ c++ and like
Re: [go-nuts] Re: I am not in favor of generics.
> On Tue, 18 Sep 2018 15:22:01 -0700 (PDT) mhhc...@gmail.com wrote:
The **stated** goal for adding some kind of generics to Go is
and always was "how to not repeat writing same code just for a type".
Now above practical goal, in minds of many, somewhat morphed
to "Yeah, lets have real true generics so we can write/reuse
smart and clever code we once upon a time wrote for c++/java".
"So we need a way of expressing generic data in terms of other
generic data then use abstract alghoritm on that".
(Yep, team's proposal use: "in terms of operations")
It now poisons all the proposals I've seen with syntax that
forces **user** of the code to **repeat** at the **call site**
type identifier for the sake of "code instantiation".
Why? I think that's a mark of "one proper way for doing generics" burnt
on the popular mindset. As hard to overcome as notion that one needs
'implements/implementing' to use interfaces.
Does Go2 should have "implements" keyword added too?
`type mytype struct{...} : implements io.Writer, ..., ...`
What?! "Compiler knows whether your type satisfies an interface"
Yeah, and at the call site compiler **does know** the parameter
type too. This is the CGG basis.
1. Find a way to write "some Go code" that is suitable for set of
types that have "something" in common.
2. Find a way to describe the set via the "something common"
that implementation for said set will use on objects of matching types.
3. It **MUST** read as Go: no instantiation at call site.
On Tue, 18 Sep 2018 15:22:01 -0700 (PDT)
mhhc...@gmail.com wrote:
> I was referring to this code
>
> func (x type []K) Sum() (r type K) {
> }
>
> I did not understand how "// For var x []AnyType. ANY. " relates to
> previous code.
Previous code example was specific to `big.Int` type. Next I gave
a really generic usage example via the constraint that already is
described in CGG proposal: "type with given method implemented".
With that constraint func Sum can be called on _any_ type that has
a method (*T) Add(T,T). And someone writing new code needs not to
change generic lib (as imputed), but she needs to provide for her
non-numeric or peculiar type a method (*T) Add(T,T). Then Sum works.
> for your question about the rune, i guess it d be like this
[...]
> Consider Z,K as virtual types to be inferred from the call site.
Progress! As to inferred :)
But I wanted return to be a string with sum of runes from all
input strings :) Leave it.
In CGG such specialization takes place in a single to find and simple
to **read** 'case' code. The proposal's example Sum already has a single
piece of code that will be **reused** for all numerical types that user
**might** declare off builtin. With only two for type cases CGG's generic
Sum spans all types with numerical base and all types that provide their own
"me plus operator". With one case more it allows for set of types that have
"plus me operator". Code that can and will run for multitude of user types.
Yet I still hear stubborn "not reusable!, not reusable! not generic!".
> In regards to Russ Cox proposal this code is missing
> their explicitly declared contracts and the function instances declaration.
> On the other hand, this is so much more readable *to me*.
The "real true generics" proposals are readable to people who took the
time and the training to accommodate to such List>
syntactical mess. But it is **against** Go philosophy of "readability first".
It excludes the legion who finds mental instantiations cumbersome at
reading time. It shifts their thought from "what this will do" to "in what
shape it will be".
> maybe it looks likes c++, i did not think it was a concern
> as long as it respected desired behaviors of good error reporting,
It IS a MAIN concern. In fact it is a concern that the Go
team explicitly stated as a reason why Go1 is generics free.
> good readability,
It has **no** readability for all but c++/java conditioned
and is an inexhaustible source of confusion in other languages
> ease of usage.
leading to ubiquitous C in java/c++ application of generic libs.
> speed of compilation,
[I assume it was not about c++ compiling]
With CGG a single significant change to current gc parsing will
be in marking 'func' node so parser could swap the subtree when
it will see 'for type' while in declaration body.
The only bigger chunk of new code in gc will be for contract
parsing and matching. Everything else needed for fast CGG
implementation already is working in the current gc.
[ c++ and like approach ]
> proven useful
Proven as a source of confusion and bugs in analysis
linked above in thread (thanks for the link, Robert :).
> and workable etc
Workable and ubiquitous. Like 'implements' before Go.
> Anyways, I am polluting the thread against this proposal, sorry for that.
It is not a pollution, really. I am glad I can discuss both "we need no
generics" and "we need practical approach" topics with avid users of
c++/java style generics. It may show
Re: [go-nuts] Re: I am not in favor of generics.
I was referring to this code
func (x type []K) Sum() (r type K) {
for type switch {
case K range int64(), uint64(), float64(), complex128():
for _, v := range x {
r += v
}
case K big.Int:
for _, v := range x {
r.Add(r,v)
}
break // or return in every case instead
}
return
}
I did not understand how "// For var x []AnyType. ANY. " relates to
previous code.
for your question about the rune, i guess it d be like this
func Sum(some []K, add func(l,r K) K) (ret K) {
for _, v := range some {
ret = add(ret, v)
}
return ret
}
func addOperator(l,r Z)Z{
return l+r
}
func main(){
total := Sum([]rune("whatever"), addOperator)
}
Consider Z,K as virtual types to be inferred from the call site.
In regards to Russ Cox proposal this code is missing
their explicitly declared contracts and the function instances declaration.
On the other hand, this is so much more readable *to me*.
maybe it looks likes c++, i did not think it was a concern
as long as it respected desired behaviors of good error reporting,
good readability, ease of usage, speed of compilation,
proven useful and workable etc
in regards to all those factors Russ Cox knows way better so he s probably
right,
yet the link provided by Robert is extremely interesting, repeating it here
https://www.researchgate.net/publication/236644412_Adoption_and_Use_of_Java_Generics
This was also an interesting reading
https://www.researchgate.net/publication/273718701_The_Reaction_of_Open-Source_Projects_to_New_Language_Features_An_Empirical_Study_of_C_Generics
Just quoting from it
Frankel [Fra 9 3]found that generics were not
widely used in Ada. Later, the principal designer of Ada suggested that, if
he could,
he would eliminate parameterized types, because they were “less useful than
originally
thought” [RSB05].
Anyways, I am polluting the thread against this proposal, sorry for that.
On Tuesday, September 18, 2018 at 10:54:02 PM UTC+2, ohir wrote:
> On Tue, 18 Sep 2018 10:11:52 -0700 (PDT)
> mhh...@gmail.com wrote:
>
> > I agree with Robert, this is not re usable.
>
> What is not reusable? A generic Sum function allowed by
> the CGG that can sum any type of any base that accidentally
> has anything countable in it?
>
> > I much prefer this
> >
> > func Sum(some []K, add func(l,r K) K) (ret K) {
> > for _, v := range some {
> > ret = add(ret, v)
> > }
> > return ret
> > }
> >
> > func main(){
>
>
> > total := Sum([]int{1,2,3,4}, func(l,r int) int {return l+r})
> > }
>
> How clever and generic it looks. Generic, javish and cpluplusish.
> And how readable call site it gave.
>
> In CGG Go user code call is exactly the same for ANY type.
>
> total := Sum(x) // For var x []AnyType. ANY.
>
> var x []string
> total := Sum(x)
>
> may return sum of all runes in all strings and sprintf-ed to
> the resulting string.
>
> > this is not re usable.
>
> How can I call your example to get string result of sum of all
> runes? CGG's is as with any other type: `total := Sum(x)`
>
> --
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE
>
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: I am not in favor of generics.
the way to explain it is this: *support for using
type-specific-but-parameterized written by A by caller B with their own
types not anticipated or known by A; the ability for B to easily say, "I
want A's excellent feature and I want to use it with my special B-only data
type."*
this cannot happen with a switch in A's code unless B rewrites it.
for a fixed set of types, this is possible and good. i rewrote the sort
package so that sort.Sort() has just this kind of type switch. if the slice
is byte, short, ... float,... string then it dispatches to a type-specific
version that is macro instantiated from one of three versions (integer,
float, string). this pays the interface tax once rather than n log n times.
it is 2x faster plus it is also parallel for another ~ 3/4 ncpus speedup.
that's my kind of code. even the most limited kind of generic can handle
this use.
but to make it work for a user's own types without code change? that needs
a greater magic.
On Tue, Sep 18, 2018 at 2:57 PM robert engels wrote:
> If you have type checking / casting / type select, whatever you want to
> call it in the “generic code”, it is not generic, and not re-usable.
>
> You can’t possibly know all the possible types, there may even be more
> additional primitive types, so the code is not resilient - Go 2.1 and all
> of your library code breaks?
>
> The caller will not have access to the source code (and certainly not want
> to read it to call a function). Nothing will be obvious as to what Sum can
> work on or what it does - in fact you can have very subtle errors because
> the code is duplicated across types.
>
> Besides those problems, even if it was somehow workable, the syntax reuses
> keywords in non-standard ways (for example even if this was adopted, why
> wouldn’t the syntax be:
>
> switch K {
> case (int64,unint64,…):
> blah blah blah
> case big.Int
> blah blah blah
> default:
> panic // implied
> }
>
> The compiler already knows K is a type…
>
> And yet more problems, because you probably need every combination of
> types if it has more than one, (depending on what the method does) — you
> need an n*n number' of case statements to implement it….
>
> I am just being realistic, and I don’t mean to be harsh, but I don’t think
> your proposal is going to be accepted, and I think it might be better if
> you spent more time listening to the criticism, and maybe reworking, than
> trying to defend it. I guess there is always the chance I don’t get it, but
> I think I do…
>
> Not sure how else to explain it.
>
>
> > On Sep 18, 2018, at 3:53 PM, Wojciech S. Czarnecki
> wrote:
> >
> > On Tue, 18 Sep 2018 10:11:52 -0700 (PDT)
> > mhhc...@gmail.com wrote:
> >
> >> I agree with Robert, this is not re usable.
> >
> > What is not reusable? A generic Sum function allowed by
> > the CGG that can sum any type of any base that accidentally
> > has anything countable in it?
> >
> >> I much prefer this
> >>
> >> func Sum(some []K, add func(l,r K) K) (ret K) {
> >> for _, v := range some {
> >>ret = add(ret, v)
> >> }
> >> return ret
> >> }
> >>
> >> func main(){
> >
> >
> >> total := Sum([]int{1,2,3,4}, func(l,r int) int {return l+r})
> >> }
> >
> > How clever and generic it looks. Generic, javish and cpluplusish.
> > And how readable call site it gave.
> >
> > In CGG Go user code call is exactly the same for ANY type.
> >
> > total := Sum(x) // For var x []AnyType. ANY.
> >
> > var x []string
> > total := Sum(x)
> >
> > may return sum of all runes in all strings and sprintf-ed to
> > the resulting string.
> >
> >> this is not re usable.
> >
> > How can I call your example to get string result of sum of all
> > runes? CGG's is as with any other type: `total := Sum(x)`
> >
> > --
> > Wojciech S. Czarnecki
> > << ^oo^ >> OHIR-RIPE
> >
> > --
> > 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+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
*Michael T. jonesmichael.jo...@gmail.com *
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: I am not in favor of generics.
If you have type checking / casting / type select, whatever you want to call it
in the “generic code”, it is not generic, and not re-usable.
You can’t possibly know all the possible types, there may even be more
additional primitive types, so the code is not resilient - Go 2.1 and all of
your library code breaks?
The caller will not have access to the source code (and certainly not want to
read it to call a function). Nothing will be obvious as to what Sum can work on
or what it does - in fact you can have very subtle errors because the code is
duplicated across types.
Besides those problems, even if it was somehow workable, the syntax reuses
keywords in non-standard ways (for example even if this was adopted, why
wouldn’t the syntax be:
switch K {
case (int64,unint64,…):
blah blah blah
case big.Int
blah blah blah
default:
panic // implied
}
The compiler already knows K is a type…
And yet more problems, because you probably need every combination of types if
it has more than one, (depending on what the method does) — you need an n*n
number' of case statements to implement it….
I am just being realistic, and I don’t mean to be harsh, but I don’t think your
proposal is going to be accepted, and I think it might be better if you spent
more time listening to the criticism, and maybe reworking, than trying to
defend it. I guess there is always the chance I don’t get it, but I think I do…
Not sure how else to explain it.
> On Sep 18, 2018, at 3:53 PM, Wojciech S. Czarnecki wrote:
>
> On Tue, 18 Sep 2018 10:11:52 -0700 (PDT)
> mhhc...@gmail.com wrote:
>
>> I agree with Robert, this is not re usable.
>
> What is not reusable? A generic Sum function allowed by
> the CGG that can sum any type of any base that accidentally
> has anything countable in it?
>
>> I much prefer this
>>
>> func Sum(some []K, add func(l,r K) K) (ret K) {
>> for _, v := range some {
>>ret = add(ret, v)
>> }
>> return ret
>> }
>>
>> func main(){
>
>
>> total := Sum([]int{1,2,3,4}, func(l,r int) int {return l+r})
>> }
>
> How clever and generic it looks. Generic, javish and cpluplusish.
> And how readable call site it gave.
>
> In CGG Go user code call is exactly the same for ANY type.
>
> total := Sum(x) // For var x []AnyType. ANY.
>
> var x []string
> total := Sum(x)
>
> may return sum of all runes in all strings and sprintf-ed to
> the resulting string.
>
>> this is not re usable.
>
> How can I call your example to get string result of sum of all
> runes? CGG's is as with any other type: `total := Sum(x)`
>
> --
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: I am not in favor of generics.
On Tue, 18 Sep 2018 10:11:52 -0700 (PDT)
mhhc...@gmail.com wrote:
> I agree with Robert, this is not re usable.
What is not reusable? A generic Sum function allowed by
the CGG that can sum any type of any base that accidentally
has anything countable in it?
> I much prefer this
>
> func Sum(some []K, add func(l,r K) K) (ret K) {
> for _, v := range some {
> ret = add(ret, v)
> }
> return ret
> }
>
> func main(){
> total := Sum([]int{1,2,3,4}, func(l,r int) int {return l+r})
> }
How clever and generic it looks. Generic, javish and cpluplusish.
And how readable call site it gave.
In CGG Go user code call is exactly the same for ANY type.
total := Sum(x) // For var x []AnyType. ANY.
var x []string
total := Sum(x)
may return sum of all runes in all strings and sprintf-ed to
the resulting string.
> this is not re usable.
How can I call your example to get string result of sum of all
runes? CGG's is as with any other type: `total := Sum(x)`
--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: I am not in favor of generics.
Thomas, Good morning old friend. Yes the implementation of axiomized arithmetic has proven difficult. Not that it is too hard, but because (I think) it requires a mindset alien to most developers. It works very well in the symbolic algebra system Axiom which is the acme; A matrix is not just "a matrix" but a 2D "matrix of integers taken from a specified field." The precision and clarity are high and the thinking required to state just what things are is also high. This works here, and pretty well in Mathematica, but really has no counterpart in computer arithmetic where even addition may violate the rules of mathematics. It would be nice to say that a Complex() or Quaternion() was a tuple of Numbers() and have it be true that fully performant big float complex math could be expressed that way, Very nice indeed. Something I look at,. But, it seems ambitious and suggests that built-in complex types still have a home. I believe average Go code will be better if there are map-quality llrb trees, stacks, sets, ... for the taking, just as if tuples were a first class thing. There were horrors in STL's evolution, but by now, everyone gets such data structures right the first time they use them, just as they do now with Go maps. Michael On Tue, Sep 18, 2018 at 11:53 AM wrote: > Eric, > > This is the sort of situation where a tool could help. > > If the tool detects that you've written a generic type/function but only > then instantiated it once, that could lead you to rewrite the type/function > non-generically for the type(s) actually used in the instantiation. > > Alan > > On Tuesday, September 18, 2018 at 6:38:34 PM UTC+1, Eric Johnson wrote: >> >> >> >> On Tue, Sep 18, 2018 at 6:21 AM Robert Engels >> wrote: >> >>> I am going to refer everyone involved in this discussion on generics to >>> this once again. I know it is long, read the summary... but it’s important: >>> >>> >>> https://www.researchgate.net/publication/236644412_Adoption_and_Use_of_Java_Generics >>> >> >> I'm skimming that paper. Thanks for sharing. Paper definitely identifies >> benefits for adding generics. >> >> This quote jumped out at me for its relevance to this discussion: >> "We observed parameterization of 1152 types, but actually found about 46 >> % of these types (532) only had exactly one type argument ever used >> throughout the project’s history, suggesting that needless or premature >> generification of objects occurs fairly frequently.We observed >> parameterization of 1152 types, but actually found about 46 % of these >> types (532) only had exactly one type argument ever used throughout the >> project’s history, suggesting that needless or premature generification of >> objects occurs fairly frequently." >> >> Put in the term of this discussion thread, the study notes that about 45% >> of the time (for the Java projects studied), portions of the code get >> harder to read, with little or no clear benefit. There's no basis for >> thinking that the same problems will or won't occur with any generics added >> to Go, but it seems like a reasonable place to point to for concerns >> driving this thread. >> >> Eric. >> >> >>> >>> On Sep 18, 2018, at 7:52 AM, Wojciech S. Czarnecki >>> wrote: >>> >>> On Tue, 18 Sep 2018 04:38:55 -0700 (PDT) >>> ffm...@web.de wrote: >>> >>> Every average Joe Java boilerplate coder gets along with generics. >>> >>> Barely, if at all, understanding whats under. >>> >>> "Smart Copy Paste ... A book for normal programmers" >>> >>> https://www.amazon.com/Smart-Paste-Stack-Overflow-other-ebook/dp/B01EHI5RQM >>> >>> But even there you can manage without thinking and just doing >>> >>> trial and error if you wanted to. >>> >>> >>> OP, I and many others want to defend Gol off this very attitude. >>> Go is among few contemporary languages that allows me to fully >>> understand what my resulting binary will do, down to the syscall >>> level. Thats precious. >>> >>> >>> I think it will neither be tricky to make use of nor to read the code. >>> >>> >>> I claim opposite. All and any Gopher will be expected to cope with hard >>> to >>> read and yet harder to understand generic code. Even if she herself will >>> vowed not to use it. In a short while we all will be obeying first Java's >>> commandment "thou shalt not peek under". >>> >>> >>> -- >>> Wojciech S. Czarnecki >>> << ^oo^ >> OHIR-RIPE >>> >>> -- >>> 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/3ia8XrUgqOg/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>>
Re: [go-nuts] Re: I am not in favor of generics.
Eric, This is the sort of situation where a tool could help. If the tool detects that you've written a generic type/function but only then instantiated it once, that could lead you to rewrite the type/function non-generically for the type(s) actually used in the instantiation. Alan On Tuesday, September 18, 2018 at 6:38:34 PM UTC+1, Eric Johnson wrote: > > > > On Tue, Sep 18, 2018 at 6:21 AM Robert Engels > wrote: > >> I am going to refer everyone involved in this discussion on generics to >> this once again. I know it is long, read the summary... but it’s important: >> >> >> https://www.researchgate.net/publication/236644412_Adoption_and_Use_of_Java_Generics >> > > I'm skimming that paper. Thanks for sharing. Paper definitely identifies > benefits for adding generics. > > This quote jumped out at me for its relevance to this discussion: > "We observed parameterization of 1152 types, but actually found about 46 % > of these types (532) only had exactly one type argument ever used > throughout the project’s history, suggesting that needless or premature > generification of objects occurs fairly frequently.We observed > parameterization of 1152 types, but actually found about 46 % of these > types (532) only had exactly one type argument ever used throughout the > project’s history, suggesting that needless or premature generification of > objects occurs fairly frequently." > > Put in the term of this discussion thread, the study notes that about 45% > of the time (for the Java projects studied), portions of the code get > harder to read, with little or no clear benefit. There's no basis for > thinking that the same problems will or won't occur with any generics added > to Go, but it seems like a reasonable place to point to for concerns > driving this thread. > > Eric. > > >> >> On Sep 18, 2018, at 7:52 AM, Wojciech S. Czarnecki > > wrote: >> >> On Tue, 18 Sep 2018 04:38:55 -0700 (PDT) >> ffm...@web.de wrote: >> >> Every average Joe Java boilerplate coder gets along with generics. >> >> Barely, if at all, understanding whats under. >> >> "Smart Copy Paste ... A book for normal programmers" >> >> https://www.amazon.com/Smart-Paste-Stack-Overflow-other-ebook/dp/B01EHI5RQM >> >> But even there you can manage without thinking and just doing >> >> trial and error if you wanted to. >> >> >> OP, I and many others want to defend Gol off this very attitude. >> Go is among few contemporary languages that allows me to fully >> understand what my resulting binary will do, down to the syscall >> level. Thats precious. >> >> >> I think it will neither be tricky to make use of nor to read the code. >> >> >> I claim opposite. All and any Gopher will be expected to cope with hard to >> read and yet harder to understand generic code. Even if she herself will >> vowed not to use it. In a short while we all will be obeying first Java's >> commandment "thou shalt not peek under". >> >> >> -- >> Wojciech S. Czarnecki >> << ^oo^ >> OHIR-RIPE >> >> -- >> 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/3ia8XrUgqOg/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 the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: I am not in favor of generics.
On Tue, Sep 18, 2018 at 6:21 AM Robert Engels wrote: > I am going to refer everyone involved in this discussion on generics to > this once again. I know it is long, read the summary... but it’s important: > > > https://www.researchgate.net/publication/236644412_Adoption_and_Use_of_Java_Generics > I'm skimming that paper. Thanks for sharing. Paper definitely identifies benefits for adding generics. This quote jumped out at me for its relevance to this discussion: "We observed parameterization of 1152 types, but actually found about 46 % of these types (532) only had exactly one type argument ever used throughout the project’s history, suggesting that needless or premature generification of objects occurs fairly frequently.We observed parameterization of 1152 types, but actually found about 46 % of these types (532) only had exactly one type argument ever used throughout the project’s history, suggesting that needless or premature generification of objects occurs fairly frequently." Put in the term of this discussion thread, the study notes that about 45% of the time (for the Java projects studied), portions of the code get harder to read, with little or no clear benefit. There's no basis for thinking that the same problems will or won't occur with any generics added to Go, but it seems like a reasonable place to point to for concerns driving this thread. Eric. > > On Sep 18, 2018, at 7:52 AM, Wojciech S. Czarnecki > wrote: > > On Tue, 18 Sep 2018 04:38:55 -0700 (PDT) > ffm2...@web.de wrote: > > Every average Joe Java boilerplate coder gets along with generics. > > Barely, if at all, understanding whats under. > > "Smart Copy Paste ... A book for normal programmers" > https://www.amazon.com/Smart-Paste-Stack-Overflow-other-ebook/dp/B01EHI5RQM > > But even there you can manage without thinking and just doing > > trial and error if you wanted to. > > > OP, I and many others want to defend Gol off this very attitude. > Go is among few contemporary languages that allows me to fully > understand what my resulting binary will do, down to the syscall > level. Thats precious. > > > I think it will neither be tricky to make use of nor to read the code. > > > I claim opposite. All and any Gopher will be expected to cope with hard to > read and yet harder to understand generic code. Even if she herself will > vowed not to use it. In a short while we all will be obeying first Java's > commandment "thou shalt not peek under". > > > -- > Wojciech S. Czarnecki > << ^oo^ >> OHIR-RIPE > > -- > 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+unsubscr...@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/3ia8XrUgqOg/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: I am not in favor of generics.
I agree with Robert, this is not re usable.
I much prefer this
func Sum(some []K, add func(l,r K) K) (ret K) {
for _, v := range some {
ret = add(ret, v)
}
return ret
}
func main(){
total := Sum([]int{1,2,3,4}, func(l,r int) int {return l+r})
}
On Tuesday, September 18, 2018 at 5:59:18 PM UTC+2, ohir wrote:
>
> On Tue, 18 Sep 2018 08:26:29 -0700 (PDT)
> alan...@gmail.com wrote:
>
> > There's no way that your generic Sum function can deal with big.Int
>
> Oh, with CGG (https://github.com/ohir/gonerics) of course there is:
>
> func (x type []K) Sum() (r type K) {
> for type switch {
> case K range int64(), uint64(), float64(), complex128():
>for _, v := range x {
> r += v
>}
> case K big.Int:
>for _, v := range x {
> r.Add(r,v)
>}
> break // or return in every case instead
> }
> return
> }
>
> :) Your welcome.
>
> > Alan
> >
>
> --
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE
>
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: I am not in favor of generics.
On Tue, 18 Sep 2018 11:10:00 -0500
robert engels wrote:
> I’ve said many time, the CGG example you cite here is not generic code.
I do not want neither write nor **READ** Go++ code.
CGG is called Craftsman's for a reason.
Its for writing and **reading** real production code. It disallows, by the
very construction, fancy recurrent types and other metaprogramming that
allows "clever guys" to encipher unreadable math with yet less readable
syntax.
> I want to pass a different user type and use that method I can’t, I need to
> change the source of Sum(). That is not generic programming...
Wrong! CGG allows operations in terms of base type (thats the num case) And
in terms what a type have or can. It's just a matter of contract.
Any person who actually got to **read** and understand CGG proposal would
spot the possibility of more generic contract by oneself:
func (x type []K) Sum() (r type K) {
for type switch {
case K range int64(), uint64(), float64(), complex128():
for _, v := range x {
r += v
}
// case K big.Int: was a simple example for Alan's stated problem
// lets make it more general for Robert:
// allow for any type that has a Sum (to itself) method:
case K (*K) Add(K, K):
for _, v := range x {
r.Add(r,v)
}
// Or, that has a value method that returns sum with self
case K (K) Add(K) K:
for _, v := range x {
r = r.Add(v)
}
break // or return in every case instead
}
return
}
> I need to change the source of Sum().
It is **me** as a generic implementer to change the source of Sum, or to
write it for some special cases as the value method case above.
If its in a lib, raise issue. I'll answer why I have omitted your outstanding
type. Or I'll implement it.
In either case, you can see the source and infer whether your type will pass
just by reading straight Go code slightly guarded by the constraints on
**types**.
--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: I am not in favor of generics.
I’ve said many time, the CGG example you cite here is not generic code. If I
want to pass a different user type and use that method I can’t, I need to
change the source of Sum(). That is not generic programming...
> On Sep 18, 2018, at 10:58 AM, Wojciech S. Czarnecki wrote:
>
> On Tue, 18 Sep 2018 08:26:29 -0700 (PDT)
> alan.f...@gmail.com wrote:
>
>> There's no way that your generic Sum function can deal with big.Int
>
> Oh, with CGG (https://github.com/ohir/gonerics) of course there is:
>
> func (x type []K) Sum() (r type K) {
> for type switch {
> case K range int64(), uint64(), float64(), complex128():
> for _, v := range x {
> r += v
> }
> case K big.Int:
> for _, v := range x {
> r.Add(r,v)
> }
> break // or return in every case instead
> }
> return
> }
>
> :) Your welcome.
>
>> Alan
>>
>
> --
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: I am not in favor of generics.
> On Sep 18, 2018, at 9:51 AM, Wojciech S. Czarnecki wrote: > > On Tue, 18 Sep 2018 08:19:13 -0500 > Robert Engels wrote: > >> So even when using generics you still need to be able to write >> understandable code. > > **need to be able to write understandable code** > Yes. This thread is about whether within Go generics proposal this is possible > and if not possible - as it seems - how to prevent disaster that might stem > from current proposal's adoption. > >> Go doesn’t need generics, at least not full featured ones. > :) Thank you for your support. > > > P.S. >> it is not as fast as Java and never will be because it can’t > > Depends of metrics and requirements. Considering industry's PoV Go so far is > the fastest language available. While Java indeed can be faster at > code execution, Go can be tenfold faster regarding "dev warmup", > compiling, testing and deployment times. And that matters the most to the > most of users. It is yet more apparent within product's evolution and > maintenance periods. > > I don’t think there is any evidence as far as compiling, testing and deployment times. Deployment is definitely simpler for a small app (single binary), if not, the configuration issue is probably the same. Also, people don’t talk about what will happen when security bugs are discovered in the Go runtime/stdlib ? You need to recompile and redistribute all of the binaries ever built… With Java you just update the JVM, and there have been efficient processes for doing this for decades. Warm-up time for optimal code execution in Java is still and issue but that has been addressed pretty well in IBM’s J9 JVM, and also the Azul Zing with ReadyNow!. The lack of declared interfaces and limited, untyped error handling in Go make it HARDER for large applications during evolution and maintenance, not simpler (as compared to Java). Go excels for systems level processes - small in functional scope - where memory safety and performance matter. > -- > Wojciech S. Czarnecki > << ^oo^ >> OHIR-RIPE > > -- > 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+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: I am not in favor of generics.
One thing I've always liked about Go is the ability to define your own
types based on the built-in ones. Although the built-ins don't have methods
themselves, you can still add them to your own types and satisfy interfaces
in that way.
This enables us to define simple collection types such as stacks and queues
whose underlying type is a slice of values and give them methods such as
Push, Peek and Pop. We then no longer need to think about how to achieve
these operations by operating on the slice directly.
The trouble at the moment is that if you want, say, a stack of ints or a
stack of strings, you either have to copy what is essentially the same
code for each type or use interface{}.
If generics is added, you'd just need to declare your variable to be a
stack(int), stack(string) or stack(whatever) and you'd then have a
type-safe, performant container without further ado.
Now, even if there was only one constraint - declaring that a type was
'Comparable' i.e. supported the == and != operators, I still think that
generics would be worth adding for all the scenarios which that would
enable.
You only need to look at the standard libraries of other popular statically
typed languages such as Java and C# to see what can be achieved with little
or no constraints.
However, in an ideal world, there's lots of other stuff you'd like to do as
well and this is where the problems start. To take a very simple example,
if you want to write a generic Sum function which can sum the values of a
slice of any numeric type, then you need to use the '+' operator and you
therefore need some way of telling the compiler that you only want to use
types which support that operator.
Now (ignoring 'string') the only types which do support '+' are the
built-in numeric types (integer, floating point, complex) and any types you
define yourself based on them.
There's no way that your generic Sum function can deal with big.Int because
it doesn't have a '+' operator and Go doesn't support operator overloading.
Using an 'Add' method instead won't work as int, float64 etc. don't have
methods.
So, when Thomas says in his post that numbers are a problem - he's right,
they are - and, in particular there's a dichotomy between the built-in and
user-defined numeric types.
However, I don't think this is a reason for giving up altogether on this -
it's still useful to have generics for the built-ins only. But you do need
to come up with a constraint system which is simple enough for everybody to
understand but expressive enough to do what you want and I have faith that
the Go team will eventually converge on such a system even if the initial
draft (IMO) falls short on the simplicity front.
In response to worries that a large Go team won't be able to work together
if some use generics and some don't, I would make these points:
1. In my experience of various other languages, most folks don't write
their own generic types/functions - they just use a library. I don't
necessarily see it as a problem if one programmer prefers to use a generic
library and another uses a non-generic library and, as I said earlier, I
suspect the latter might be less adverse to generics when they see how
convenient they are to use.
2. There is no way that the Go team are going to adopt generics in such a
way that it is not a good fit with the rest of the language. So any worries
that Go is going to end up like C++ (with everybody using a different
subset of the language) or Python (with the version 2/3 split) are
unfounded in my opinion.
Alan
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: I am not in favor of generics.
On Tue, 18 Sep 2018 08:19:13 -0500 Robert Engels wrote: > So even when using generics you still need to be able to write > understandable code. **need to be able to write understandable code** Yes. This thread is about whether within Go generics proposal this is possible and if not possible - as it seems - how to prevent disaster that might stem from current proposal's adoption. > Go doesn’t need generics, at least not full featured ones. :) Thank you for your support. P.S. > it is not as fast as Java and never will be because it can’t Depends of metrics and requirements. Considering industry's PoV Go so far is the fastest language available. While Java indeed can be faster at code execution, Go can be tenfold faster regarding "dev warmup", compiling, testing and deployment times. And that matters the most to the most of users. It is yet more apparent within product's evolution and maintenance periods. -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: I am not in favor of generics.
I am going to refer everyone involved in this discussion on generics to this once again. I know it is long, read the summary... but it’s important: https://www.researchgate.net/publication/236644412_Adoption_and_Use_of_Java_Generics > On Sep 18, 2018, at 7:52 AM, Wojciech S. Czarnecki wrote: > > On Tue, 18 Sep 2018 04:38:55 -0700 (PDT) > ffm2...@web.de wrote: > >> Every average Joe Java boilerplate coder gets along with generics. > Barely, if at all, understanding whats under. > > "Smart Copy Paste ... A book for normal programmers" > https://www.amazon.com/Smart-Paste-Stack-Overflow-other-ebook/dp/B01EHI5RQM > >> But even there you can manage without thinking and just doing >> trial and error if you wanted to. > > OP, I and many others want to defend Gol off this very attitude. > Go is among few contemporary languages that allows me to fully > understand what my resulting binary will do, down to the syscall > level. Thats precious. > > >> I think it will neither be tricky to make use of nor to read the code. > > I claim opposite. All and any Gopher will be expected to cope with hard to > read and yet harder to understand generic code. Even if she herself will > vowed not to use it. In a short while we all will be obeying first Java's > commandment "thou shalt not peek under". > > > -- > Wojciech S. Czarnecki > << ^oo^ >> OHIR-RIPE > > -- > 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+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: I am not in favor of generics.
Here is a very common problem with generics... Everyone understands the concept of a tuple/pair. Pretty easy, you have getElement0 and getElement1 methods. Now a piece of code needs a KeyValue pair used in a map. So, with generics someone says, oh, I already have this pair class, I’ll just use that and declare my types, so Pair. This is wrong, you need to write the code for KeyValue that contains a Pair, with KeyValue The former would work but then the code is littered with getElement0 instead of getKey It works but much more difficult to understand and maintain. So even when using generics you still need to be able to write understandable code. Having a generic KeyValue pair when working with maps makes the code much more readable and type safe than for example working with sync.Map today. Generics are wonderful when done simply. Because of Gos static compilation and coupled with a user base that doesn’t truly understand the Go performance profile (hint, it is not as fast as Java and never will be because it can’t - but more importantly it doesn’t matter) Go is going to end of with something as complex and obtuse as C++ templates (with concepts). Not a good fit for Gos development community or its long-term viability. Go doesn’t need generics, at least not full featured ones. > On Sep 18, 2018, at 7:52 AM, Wojciech S. Czarnecki wrote: > > On Tue, 18 Sep 2018 04:38:55 -0700 (PDT) > ffm2...@web.de wrote: > >> Every average Joe Java boilerplate coder gets along with generics. > Barely, if at all, understanding whats under. > > "Smart Copy Paste ... A book for normal programmers" > https://www.amazon.com/Smart-Paste-Stack-Overflow-other-ebook/dp/B01EHI5RQM > >> But even there you can manage without thinking and just doing >> trial and error if you wanted to. > > OP, I and many others want to defend Gol off this very attitude. > Go is among few contemporary languages that allows me to fully > understand what my resulting binary will do, down to the syscall > level. Thats precious. > > >> I think it will neither be tricky to make use of nor to read the code. > > I claim opposite. All and any Gopher will be expected to cope with hard to > read and yet harder to understand generic code. Even if she herself will > vowed not to use it. In a short while we all will be obeying first Java's > commandment "thou shalt not peek under". > > > -- > Wojciech S. Czarnecki > << ^oo^ >> OHIR-RIPE > > -- > 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+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: I am not in favor of generics.
On Tue, 18 Sep 2018 04:38:55 -0700 (PDT) ffm2...@web.de wrote: > Every average Joe Java boilerplate coder gets along with generics. Barely, if at all, understanding whats under. "Smart Copy Paste ... A book for normal programmers" https://www.amazon.com/Smart-Paste-Stack-Overflow-other-ebook/dp/B01EHI5RQM > But even there you can manage without thinking and just doing > trial and error if you wanted to. OP, I and many others want to defend Gol off this very attitude. Go is among few contemporary languages that allows me to fully understand what my resulting binary will do, down to the syscall level. Thats precious. > I think it will neither be tricky to make use of nor to read the code. I claim opposite. All and any Gopher will be expected to cope with hard to read and yet harder to understand generic code. Even if she herself will vowed not to use it. In a short while we all will be obeying first Java's commandment "thou shalt not peek under". -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: I am not in favor of generics.
On Tue, Sep 18, 2018 at 1:04 PM wrote:
> It would be nice, for example, to have a full range of collection types in
> the standard library without the need to use interface{}, type assertions
> and the performance overhead of 'boxing'.
>
>From the earliest days of Object Oriented Programming, the idea of abstract
data types and generic implementations of container classes has stood out
as the one (and virtually only) win for this strategy.
So let's first notice the failure: numeric types. It seems like numbers,
which fit nicely into set-theoretic classes, should be a great use of
Object Oriented structure, but as soon as you realize that the addition
operation needs to inherit from *two *separate classes a problem happens.
Smalltalk coped by having a global namespace of "priorities" for numbers,
and each numeric operation promoted the receiver or the argument as
necessary, with all kinds of really annoying manual work of just the sort
that dynamic dispatch was supposed to make unnecessary.
So Lisp had generic functions which could genuinely parameterize on the
types of more than one argument, but that still produces a disaster; to
implement addition when you have N different types requires writing
N-squared little functions. This leads to the code bloat we are familiar
with in C++ - but quadratically worse.
So numbers fail. Nobody's got a way that *actually *works. What about
containers? Also a fail. Why? Because *the implementation depends on the
use.*
A brilliant example of this was a proposed spreadsheet design. Having
noticed that X provides output windows, which can be independently moved
and updated, we'll just implement a spreadsheet by creating ten thousand
little X windows, each backed by a separate Unix process, and responsible
for displaying their value and communicating across the X server to find
the values of cells they depend on. And the server's refresh logic will
prevent unnecessary computation! Brilliant! And nothing in the
documentation of the X protocol says, "oh, by the way, that would be an
idiotic strategy".
This happens *everywhere. *We have experience that very simple types don't
require more: hash tables, arrays, pairs. But for fancy container classes?
If you want a "set" type and hash tables aren't for you, that's because
hash tables don't support operations like union and intersection. But guess
what: every implementation of union and intersection makes assumptions
about the expected use, such that misuse will result in something which is
mathematically appropriate, but a computational disaster. *There is no
generic implementation of set theoretic union and intersection which works
for all users as well as hash tables currently work for all users.*
So yes, you can implement collection classes with generics. But so what?
You don't ever want to use them. Either performance matters, and the
generic implementation will be unacceptable to anyone who isn't lucky, or
performance doesn't matter and you don't need a sophisticated collection
class at all. (Or you're in the small well-known set of data types that we
are confident *can *be implemented generically - but this is a small and
static set, and does not require general generics as part of the language.)
Thomas
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: I am not in favor of generics.
在 2018年9月18日星期二 UTC+8下午7:29:37，Chris Hopkins写道：
>
> Pondering this, my concern is that it might become too powerful. I'm
> scared this will make it harder to work out what someone has done if
> there's too much indirection and magic added on top. It feels like it could
> be a really *really* big hammer.
>
> I don't buy the argument " those who prefer to avoid generics may do so
> and carry on as they are" because go is all about large projects and code
> reuse. If you enable people to write code that the average programmer can't
> understand, then IMO that is against the philosophy of what i thought go
> was.
>
+1. Go should not become another C++, of which different people or groups
use different subsets.
Knuth save me from people writing "clever" code.
>
> Chris
> On Tuesday, 18 September 2018 12:04:15 UTC+1, alan...@gmail.com wrote:
>>
>> Although I respect the opinions expressed here, I think you might be
>> pleasantly surprised by how the proposed design would dovetail with the
>> rest of Go and make a number of things much more convenient than they are
>> at present.
>>
>> It would be nice, for example, to have a full range of collection types
>> in the standard library without the need to use interface{}, type
>> assertions and the performance overhead of 'boxing'.
>>
>> It's not an ugly design with angle brackets all over the place and most
>> of the time you'd hardly notice you were using a generic function as the
>> type parameter(s) would be automatically inferred from usage.
>>
>> Better still it would be compatible with Go 1.
>>
>> Admittedly, there's a lot of discussion over the design at present though
>> that's mainly about the constraint system. Everybody agrees that this needs
>> to be both simple and expressive though opinions differ over the best way
>> to achieve that.
>>
>> Anyway, as I said in another thread, the important thing is that the
>> existing built-in generic stuff is not interfered with, so those who prefer
>> to avoid generics may do so and carry on as they are. That way everybody
>> will be happy :)
>>
>> Alan
>>
>> On Monday, September 17, 2018 at 5:04:26 PM UTC+1,
>> jucie@zanthus.com.br wrote:
>>>
>>> Go core team is working hard to bring generics to the language because
>>> several people asked for it. With all due respect for those users and for
>>> people working hard to make generics a reality, I feel that a greater
>>> number of people would suffer after generics adoption. So, I feel compeled
>>> to manifest my opinion: sorry guys, Go with generics will be worse than Go
>>> without generics.
>>>
>>> The language strives for simplicity since its inception and that is what
>>> attracted a large part of its user base. We must think about who we will
>>> want to have in our community 10 years from now. Supporting generics would
>>> please a minority to the detriment of a large number of potential users.
>>>
>>> Today Go is easy to learn and tools are easy to implement. Please keep
>>> it that way.
>>>
>>> Thanks.
>>>
>>
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: I am not in favor of generics.
Am Dienstag, 18. September 2018 13:29:37 UTC+2 schrieb Chris Hopkins: > > Pondering this, my concern is that it might become too powerful. I'm > scared this will make it harder to work out what someone has done if > there's too much indirection and magic added on top. It feels like it could > be a really *really* big hammer. > I'm not so much scared in this way. Every average Joe Java boilerplate coder gets along with generics. It only gets a little tricky with inheritance. But even there you can manage without thinking and just doing trial and error if you wanted to. Besides that, Go does not have inheritance. So, I think it will neither be tricky to make use of nor to read the code. -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: I am not in favor of generics.
Pondering this, my concern is that it might become too powerful. I'm scared
this will make it harder to work out what someone has done if there's too
much indirection and magic added on top. It feels like it could be a really
*really* big hammer.
I don't buy the argument " those who prefer to avoid generics may do so and
carry on as they are" because go is all about large projects and code
reuse. If you enable people to write code that the average programmer can't
understand, then IMO that is against the philosophy of what i thought go
was.
Knuth save me from people writing "clever" code.
Chris
On Tuesday, 18 September 2018 12:04:15 UTC+1, alan...@gmail.com wrote:
>
> Although I respect the opinions expressed here, I think you might be
> pleasantly surprised by how the proposed design would dovetail with the
> rest of Go and make a number of things much more convenient than they are
> at present.
>
> It would be nice, for example, to have a full range of collection types in
> the standard library without the need to use interface{}, type assertions
> and the performance overhead of 'boxing'.
>
> It's not an ugly design with angle brackets all over the place and most of
> the time you'd hardly notice you were using a generic function as the type
> parameter(s) would be automatically inferred from usage.
>
> Better still it would be compatible with Go 1.
>
> Admittedly, there's a lot of discussion over the design at present though
> that's mainly about the constraint system. Everybody agrees that this needs
> to be both simple and expressive though opinions differ over the best way
> to achieve that.
>
> Anyway, as I said in another thread, the important thing is that the
> existing built-in generic stuff is not interfered with, so those who prefer
> to avoid generics may do so and carry on as they are. That way everybody
> will be happy :)
>
> Alan
>
> On Monday, September 17, 2018 at 5:04:26 PM UTC+1,
> jucie@zanthus.com.br wrote:
>>
>> Go core team is working hard to bring generics to the language because
>> several people asked for it. With all due respect for those users and for
>> people working hard to make generics a reality, I feel that a greater
>> number of people would suffer after generics adoption. So, I feel compeled
>> to manifest my opinion: sorry guys, Go with generics will be worse than Go
>> without generics.
>>
>> The language strives for simplicity since its inception and that is what
>> attracted a large part of its user base. We must think about who we will
>> want to have in our community 10 years from now. Supporting generics would
>> please a minority to the detriment of a large number of potential users.
>>
>> Today Go is easy to learn and tools are easy to implement. Please keep it
>> that way.
>>
>> Thanks.
>>
>
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: I am not in favor of generics.
+1 IMO the place generics would be useful is reducing the use of the empty interface and then a type switch. Otherwise I don't see quite what people are doing that wouldn't be better done with interfaces. In the past I mistakenly tried to declare local methods on the builtin types. Revisiting my ignorance I wonder if that would help though. I see the logic that "append and len and other inbuilt functions are generic and idiomatic, so it would be better to allow others to write their own generic functions". However I would argue that the problem could be turned on its head. It's not that other types need to be made more like the inbuilts, but that inbuilts become more like all other types. Why doesn't append have an interface requirement like the sort interface? Anyway I realise I don't understand the problem enough to wrap this up in an official proposal, but I see it as it is things like channel operations and arithmetic that are unusual and should use interfaces (under the hood), rather than everything else fitted around them. But this is probably me not understanding the problem that people are trying to solve. It's more than people wanting to neither use an empty interface, nor declare their interfaces isn't it? Chris On Monday, 17 September 2018 17:04:26 UTC+1, jucie@zanthus.com.br wrote: > > Go core team is working hard to bring generics to the language because > several people asked for it. With all due respect for those users and for > people working hard to make generics a reality, I feel that a greater > number of people would suffer after generics adoption. So, I feel compeled > to manifest my opinion: sorry guys, Go with generics will be worse than Go > without generics. > > The language strives for simplicity since its inception and that is what > attracted a large part of its user base. We must think about who we will > want to have in our community 10 years from now. Supporting generics would > please a minority to the detriment of a large number of potential users. > > Today Go is easy to learn and tools are easy to implement. Please keep it > that way. > > Thanks. > -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: I am not in favor of generics.
Although I respect the opinions expressed here, I think you might be
pleasantly surprised by how the proposed design would dovetail with the
rest of Go and make a number of things much more convenient than they are
at present.
It would be nice, for example, to have a full range of collection types in
the standard library without the need to use interface{}, type assertions
and the performance overhead of 'boxing'.
It's not an ugly design with angle brackets all over the place and most of
the time you'd hardly notice you were using a generic function as the type
parameter(s) would be automatically inferred from usage.
Better still it would be compatible with Go 1.
Admittedly, there's a lot of discussion over the design at present though
that's mainly about the constraint system. Everybody agrees that this needs
to be both simple and expressive though opinions differ over the best way
to achieve that.
Anyway, as I said in another thread, the important thing is that the
existing built-in generic stuff is not interfered with, so those who prefer
to avoid generics may do so and carry on as they are. That way everybody
will be happy :)
Alan
On Monday, September 17, 2018 at 5:04:26 PM UTC+1, jucie@zanthus.com.br
wrote:
>
> Go core team is working hard to bring generics to the language because
> several people asked for it. With all due respect for those users and for
> people working hard to make generics a reality, I feel that a greater
> number of people would suffer after generics adoption. So, I feel compeled
> to manifest my opinion: sorry guys, Go with generics will be worse than Go
> without generics.
>
> The language strives for simplicity since its inception and that is what
> attracted a large part of its user base. We must think about who we will
> want to have in our community 10 years from now. Supporting generics would
> please a minority to the detriment of a large number of potential users.
>
> Today Go is easy to learn and tools are easy to implement. Please keep it
> that way.
>
> Thanks.
>
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: I am not in favor of generics.
When I was a new Go user and didn't fully understand how to use the language, I really wanted Generics. But the more Go experience I gained, the more I realized that Generics wouldn't have helped nearly as much as I had assumed; in fact, they would have added significant complexity and probably led me to write more-difficult-to-understand code. The longer I use Go, the more beautiful it becomes. It's already elegant and powerful, and we shouldn't add fancy features just to please a crowd. Thank you Go Team! ~Christopher -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: I am not in favor of generics.
On Mon, 17 Sep 2018 11:18:51 -0700 (PDT) > Eric Johnson >> jucie.andr...@zanthus.com.br I hope that the team will make an informed decission and assesment taking into account both the opinion of the community and its good ideas to make something simpler. See all community proposals at https://github.com/golang/go/wiki/Go2GenericsFeedback > adding parameterized typed method invocations will add complexity, Not all proposals need this. Eg. CGG https://github.com/ohir/gonerics [mine's] does not change user code syntax at all. A few changes were needed for the generic code implementation but it upkeeps Go's philosophy. I hope. If it is not, please tell me. > incompatible with Go's existing language choices. I look forward to seeing > the next round of drafts and how they incorporate concerns about contracts. >> Today Go is easy to learn and tools are easy to implement. >> Please keep it that way. > I agree with that sentiment! So do I. -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: I am not in favor of generics.
On Monday, September 17, 2018 at 9:04:26 AM UTC-7, jucie@zanthus.com.br wrote: > > Go core team is working hard to bring generics to the language because > several people asked for it. With all due respect for those users and for > people working hard to make generics a reality, I feel that a greater > number of people would suffer after generics adoption. So, I feel compeled > to manifest my opinion: sorry guys, Go with generics will be worse than Go > without generics. > I think you're right, that adding parameterized typed method invocations will add complexity, and therefore people will suffer more. However, to me, it isn't obvious, without a final proposal against which to assess that concern, that the pain will outweigh the gain. Certainly, the existing proposal suffers from at least one area of considerable additional complexity - "contracts" - which is both a great way to address the problem space, and an area of new complexity incompatible with Go's existing language choices. I look forward to seeing the next round of drafts and how they incorporate concerns about contracts. > > The language strives for simplicity since its inception and that is what > attracted a large part of its user base. We must think about who we will > want to have in our community 10 years from now. Supporting generics would > please a minority to the detriment of a large number of potential users. > What pushes me in the direction of encouraging attempts to address the missing language feature of generics are two aspects: - Copy and paste coding is an enormous source of errors, and to the extent that generics addresses some of those scenarios, that is a big win for the language and the developers. Writing yet another "for ... range" loop to perform the same mutation on a very similar type is not a big deal the 2nd time, but by the time I've had to do that for a fifth time, I'm unhappy about it, for sure. (YAFRL - "yet another for ... range loop") - Go already has "generic" capabilities. "range", channels, select, and type-casting are generic language constructs, "Make", "copy", "append" all provide generic functions, and maps and slices are generic data structures. Developers certainly do not have a problem using the existing "generic" capabilities of the language, so I think there's a case to be made that they will not consider additional "generic" capability that much harder to absorb. > Today Go is easy to learn and tools are easy to implement. Please keep it > that way. > I agree with that sentiment! Eric. -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
