Re: [go-nuts] Re: Generics, please go away!

[Space A.]

 > Wait, I think I get it. Are you making a distinction between object
oriented /languages/ and object oriented /programs/ (which may or may not
be written in an object oriented language)?
You are absolutely correct, my friend, so you see, OOP is just a paradigm
in software development. Program can be entirely OOP, or partially, such as
module, or library. And you have tools such as programming languages. When
these languages provide you with instruments for building your OOP program
*out of the box*, being a first-class citizens, you could call that
language OOP. Key feature of major OOP languages is inheritance and all
supporting stuff. But you can use non-OOP language such as C, just that you
will need to add some moving parts yourself instead of using what's given
by language.

Same with CSP. Go is often called a CSP language, or language with CSP
capabilities, because it has all needed features, such as goroutines and
channels out of the box as first class objects. But this doesn't mean you
cannot write CSP program in any other language, you can, but you will
sometimes have to invent a wheel.


> For example, from my interpretation of your definition, Java and C++
would be considered object oriented languages, because they favor class
inheritance over composition. But a language like Scheme or JavaScript
would not be considered an object oriented language because they do not
have traditional class inheritance.
Exactly. Thank you for giving me hope that at the end at least some of us
living on the same planet.


пт, 1 янв. 2021 г. в 19:07, Beka Westberg :

> > First of all I feel it's more rhetoric, it's same as "Less is
> exponentially more", and "[Go] ... Arguably more object oriented than say
> Java or C++ ". I believe if you think logically "less" could not be "more",
> right, and you wouldn't insist on that? Same goes to the statement that Go
> is more object oriented. What I think he meant was "Go has even better
> compatibilities even for OOP because of composition" which also in line
> with what I said that you can use ANY language to write OOP program.
>
> Wait, I think I get it. Are you making a distinction between object
> oriented /languages/ and object oriented /programs/ (which may or may not
> be written in an object oriented language)?
>
> For example, from my interpretation of your definition, Java and C++ would
> be considered object oriented languages, because they favor class
> inheritance over composition. But a language like Scheme or JavaScript
> would not be considered an object oriented language because they do not
> have traditional class inheritance.
>
> However, it seems like you are saying that you can write an object
> oriented /program/ in any of the above languages? Each of the above
> languages allows you to create "things" that have internal mutable state,
> and can receive messages, which seems like a pretty good definition of an
> object :D Hence, object oriented programming is possible.
>
> I don't really have an opinion on this. I just want to know if my
> interpretation of your opinion was close, or way off base hehe.
>
> On Friday, January 1, 2021 at 6:05:07 AM UTC-8 Space A. wrote:
>
>> Ok I see you change a little bit your position, so I only comment on this:
>>
>> > His verbatim quote is "Go is a profoundly object oriented language.
>> Arguably more object oriented than say Java or C++". That clearly
>> contradicts your statement that Go is not an OOP language. He also goes to
>> great length to say that Go does not have inheritance (in favor of
>> composition), which, together with the first one, clearly implies that he
>> is contradicting your assertion that "OOP is all about inheritance".
>>
>> > I don't see a lot of room for interpretation here.
>>
>> Well, I do. I do believe if you truly think he meant "Go is OOP language"
>> and continue insisting you are wrong.
>>
>> 1. First of all I feel it's more rhetoric, it's same as "Less is
>> exponentially more", and "[Go] ... Arguably more object oriented than say
>> Java or C++ ". I believe if you think logically "less" could not be "more",
>> right, and you wouldn't insist on that? Same goes to the statement that Go
>> is more object oriented. What I think he meant was "Go has even better
>> compatibilities even for OOP because of composition" which also in line
>> with what I said that you can use ANY language to write OOP program.
>> 2. There is FAQ question and answer, and I do believe Rob took part in
>> answering FAQ, and this one in particular.
>>
>> Anyways as you said in the beginning of thread, Go is no a religion, Rob
>> is not Jesus, he is alive and he can explain his position if it makes any
>> sense. Maybe I'm wrong and don't understand something, that's possible. So
>> I'm not arguing for the sake of arguing.
>>
>>
>>
>>
>>
>> пт, 1 янв. 2021 г. в 16:48, Axel Wagner :
>>
>>> On Fri, Jan 1, 2021 at 1:57 PM Space A.  wrote:
>>>
 > Javascript is an incredibly popular language with 

Re: [go-nuts] Re: Generics, please go away!

[Beka Westberg]

> First of all I feel it's more rhetoric, it's same as "Less is 
exponentially more", and "[Go] ... Arguably more object oriented than say 
Java or C++ ". I believe if you think logically "less" could not be "more", 
right, and you wouldn't insist on that? Same goes to the statement that Go 
is more object oriented. What I think he meant was "Go has even better 
compatibilities even for OOP because of composition" which also in line 
with what I said that you can use ANY language to write OOP program.

Wait, I think I get it. Are you making a distinction between object 
oriented /languages/ and object oriented /programs/ (which may or may not 
be written in an object oriented language)?

For example, from my interpretation of your definition, Java and C++ would 
be considered object oriented languages, because they favor class 
inheritance over composition. But a language like Scheme or JavaScript 
would not be considered an object oriented language because they do not 
have traditional class inheritance.

However, it seems like you are saying that you can write an object oriented 
/program/ in any of the above languages? Each of the above languages allows 
you to create "things" that have internal mutable state, and can receive 
messages, which seems like a pretty good definition of an object :D Hence, 
object oriented programming is possible.

I don't really have an opinion on this. I just want to know if my 
interpretation of your opinion was close, or way off base hehe.

On Friday, January 1, 2021 at 6:05:07 AM UTC-8 Space A. wrote:

> Ok I see you change a little bit your position, so I only comment on this:
>
> > His verbatim quote is "Go is a profoundly object oriented language. 
> Arguably more object oriented than say Java or C++". That clearly 
> contradicts your statement that Go is not an OOP language. He also goes to 
> great length to say that Go does not have inheritance (in favor of 
> composition), which, together with the first one, clearly implies that he 
> is contradicting your assertion that "OOP is all about inheritance". 
>
> > I don't see a lot of room for interpretation here. 
>
> Well, I do. I do believe if you truly think he meant "Go is OOP language" 
> and continue insisting you are wrong. 
>
> 1. First of all I feel it's more rhetoric, it's same as "Less is 
> exponentially more", and "[Go] ... Arguably more object oriented than say 
> Java or C++ ". I believe if you think logically "less" could not be "more", 
> right, and you wouldn't insist on that? Same goes to the statement that Go 
> is more object oriented. What I think he meant was "Go has even better 
> compatibilities even for OOP because of composition" which also in line 
> with what I said that you can use ANY language to write OOP program.
> 2. There is FAQ question and answer, and I do believe Rob took part in 
> answering FAQ, and this one in particular.
>
> Anyways as you said in the beginning of thread, Go is no a religion, Rob 
> is not Jesus, he is alive and he can explain his position if it makes any 
> sense. Maybe I'm wrong and don't understand something, that's possible. So 
> I'm not arguing for the sake of arguing.
>
>
>
>
>
> пт, 1 янв. 2021 г. в 16:48, Axel Wagner :
>
>> On Fri, Jan 1, 2021 at 1:57 PM Space A.  wrote:
>>
>>> > Javascript is an incredibly popular language with non-inheritance OOP. 
>>> Or, at least, no inheritance at the type-level (so either way, invalidating 
>>> your statement that OOP is about type-hierarchies). 
>>>
>> This is debatable but JS is a non-OOP language.
>>>
>>
>> That's certainly a valid opinion to hold. I don't believe it, 
>> empirically, agrees with the common wisdom around it, though.
>>  
>>
>>> And yet if you wonder, there is no definition of what OOP language is. 
>>> Give it any, I don't mind. But it seems to most of us it's quite clear (by 
>>> major examples like C++ or Java) until we start arguing just for arguing.
>>>
>>
>> With this, I agree. Note, again, that it doesn't actually *matter* for 
>> the question of whether or not Go should get generics, whether we call it 
>> an OOP language or not. And yet, it has become a point of argument in this 
>> thread - AFAICT, purely for the sake of arguing.
>>
>> > Repetition does not make a false statement true. Instead of 
>>> copy-pasting yourself, it would be prudent to cite sources. For example, is 
>>> there any text book that agrees with your definition of OOP? 
>>> What exactly you disagree on? I will copy and paste once again for your 
>>> convenience =)
>>>
>>
>> There really is no need (though I recognize what you are trying to do). 
>> Let me quote a couple of your statements that I disagree with:
>> • "Go doesn't have classes and is not an OOP language."
>> • "Oh my... It is pure sophistic nonsense. OOP is all about inheritance. 
>> Not just whether you have "objects" in a language spec or not."
>> • "As I said, OOP (if we talk about language, not a program written in 
>> OOP paradigm, because you 

Re: [go-nuts] Re: Generics, please go away!

[Space A.]

Actually not "people mean the literal opposite of what they say", but
"people interpret wrongly when trying to read literally". At least I can
imagine myself saying something similar to "Go is more object oriented than
..." if it's not regarding general classification of languages. Maybe I
even did that, lol.



пт, 1 янв. 2021 г. в 17:30, Axel Wagner :

> On Fri, Jan 1, 2021 at 3:04 PM Space A.  wrote:
>
>> > I don't see a lot of room for interpretation here.
>>
>> Well, I do. I do believe if you truly think he meant "Go is OOP language"
>> and continue insisting you are wrong.
>>
>
> Okay. I don't believe "people mean the literal opposite of what they say"
> is a POV that can be argued with.
>
>
>>
>> 1. First of all I feel it's more rhetoric, it's same as "Less is
>> exponentially more", and "[Go] ... Arguably more object oriented than say
>> Java or C++ ". I believe if you think logically "less" could not be "more",
>> right, and you wouldn't insist on that? Same goes to the statement that Go
>> is more object oriented. What I think he meant was "Go has even better
>> compatibilities even for OOP because of composition" which also in line
>> with what I said that you can use ANY language to write OOP program.
>> 2. There is FAQ question and answer, and I do believe Rob took part in
>> answering FAQ, and this one in particular.
>>
>> Anyways as you said in the beginning of thread, Go is no a religion, Rob
>> is not Jesus, he is alive and he can explain his position if it makes any
>> sense. Maybe I'm wrong and don't understand something, that's possible. So
>> I'm not arguing for the sake of arguing.
>>
>>
>>
>>
>>
>> пт, 1 янв. 2021 г. в 16:48, Axel Wagner :
>>
>>> On Fri, Jan 1, 2021 at 1:57 PM Space A.  wrote:
>>>
 > Javascript is an incredibly popular language with non-inheritance
 OOP. Or, at least, no inheritance at the type-level (so either way,
 invalidating your statement that OOP is about type-hierarchies).

>>> This is debatable but JS is a non-OOP language.

>>>
>>> That's certainly a valid opinion to hold. I don't believe it,
>>> empirically, agrees with the common wisdom around it, though.
>>>
>>>
 And yet if you wonder, there is no definition of what OOP language is.
 Give it any, I don't mind. But it seems to most of us it's quite clear (by
 major examples like C++ or Java) until we start arguing just for arguing.

>>>
>>> With this, I agree. Note, again, that it doesn't actually *matter* for
>>> the question of whether or not Go should get generics, whether we call it
>>> an OOP language or not. And yet, it has become a point of argument in this
>>> thread - AFAICT, purely for the sake of arguing.
>>>
>>> > Repetition does not make a false statement true. Instead of
 copy-pasting yourself, it would be prudent to cite sources. For example, is
 there any text book that agrees with your definition of OOP?
 What exactly you disagree on? I will copy and paste once again for your
 convenience =)

>>>
>>> There really is no need (though I recognize what you are trying to do).
>>> Let me quote a couple of your statements that I disagree with:
>>> • "Go doesn't have classes and is not an OOP language."
>>> • "Oh my... It is pure sophistic nonsense. OOP is all about inheritance.
>>> Not just whether you have "objects" in a language spec or not."
>>> • "As I said, OOP (if we talk about language, not a program written in
>>> OOP paradigm, because you can use ANY language for that) is all about
>>> inheritance."
>>>
>>> And in the interest of clarity and to illustrate that I'm not just
>>> trying to argue for the sake of argument: I do agree with you that Go
>>> favors composition over inheritance. And I do agree that inheritance based
>>> OOP prioritizes type-hierarchies.
>>>
>>>
 Maybe you disagree with Rob Pike who made statements quite similar to
 what I said regarding composition in his quote I given above?

>>>
>>> If we are making an appeal to authority, I thnik you'll find he made
>>> statements that directly contradict the ones I quoted above as disagree
>>> with. And he made statements that support the ones I agree with.
>>>
>>>
 That's ridiculous. There is a question in FAQ. And answer you are aware
 of, which says Go is not OOP, which Rop Pike for sure aware of as well. And
 his wording in that video means not how you trying to interpret.

>>>
>>> His verbatim quote is "Go is a profoundly object oriented language.
>>> Arguably more object oriented than say Java or C++". That clearly
>>> contradicts your statement that Go is not an OOP language. He also goes to
>>> great length to say that Go does not have inheritance (in favor of
>>> composition), which, together with the first one, clearly implies that he
>>> is contradicting your assertion that "OOP is all about inheritance".
>>>
>>> I don't see a lot of room for interpretation here.
>>>
>>> > But either way, if you don't mind me asking: What exactly 

Re: [go-nuts] Re: Generics, please go away!

['Axel Wagner' via golang-nuts]

On Fri, Jan 1, 2021 at 3:04 PM Space A.  wrote:

> > I don't see a lot of room for interpretation here.
>
> Well, I do. I do believe if you truly think he meant "Go is OOP language"
> and continue insisting you are wrong.
>

Okay. I don't believe "people mean the literal opposite of what they say"
is a POV that can be argued with.


>
> 1. First of all I feel it's more rhetoric, it's same as "Less is
> exponentially more", and "[Go] ... Arguably more object oriented than say
> Java or C++ ". I believe if you think logically "less" could not be "more",
> right, and you wouldn't insist on that? Same goes to the statement that Go
> is more object oriented. What I think he meant was "Go has even better
> compatibilities even for OOP because of composition" which also in line
> with what I said that you can use ANY language to write OOP program.
> 2. There is FAQ question and answer, and I do believe Rob took part in
> answering FAQ, and this one in particular.
>
> Anyways as you said in the beginning of thread, Go is no a religion, Rob
> is not Jesus, he is alive and he can explain his position if it makes any
> sense. Maybe I'm wrong and don't understand something, that's possible. So
> I'm not arguing for the sake of arguing.
>
>
>
>
>
> пт, 1 янв. 2021 г. в 16:48, Axel Wagner :
>
>> On Fri, Jan 1, 2021 at 1:57 PM Space A.  wrote:
>>
>>> > Javascript is an incredibly popular language with non-inheritance OOP.
>>> Or, at least, no inheritance at the type-level (so either way, invalidating
>>> your statement that OOP is about type-hierarchies).
>>>
>> This is debatable but JS is a non-OOP language.
>>>
>>
>> That's certainly a valid opinion to hold. I don't believe it,
>> empirically, agrees with the common wisdom around it, though.
>>
>>
>>> And yet if you wonder, there is no definition of what OOP language is.
>>> Give it any, I don't mind. But it seems to most of us it's quite clear (by
>>> major examples like C++ or Java) until we start arguing just for arguing.
>>>
>>
>> With this, I agree. Note, again, that it doesn't actually *matter* for
>> the question of whether or not Go should get generics, whether we call it
>> an OOP language or not. And yet, it has become a point of argument in this
>> thread - AFAICT, purely for the sake of arguing.
>>
>> > Repetition does not make a false statement true. Instead of
>>> copy-pasting yourself, it would be prudent to cite sources. For example, is
>>> there any text book that agrees with your definition of OOP?
>>> What exactly you disagree on? I will copy and paste once again for your
>>> convenience =)
>>>
>>
>> There really is no need (though I recognize what you are trying to do).
>> Let me quote a couple of your statements that I disagree with:
>> • "Go doesn't have classes and is not an OOP language."
>> • "Oh my... It is pure sophistic nonsense. OOP is all about inheritance.
>> Not just whether you have "objects" in a language spec or not."
>> • "As I said, OOP (if we talk about language, not a program written in
>> OOP paradigm, because you can use ANY language for that) is all about
>> inheritance."
>>
>> And in the interest of clarity and to illustrate that I'm not just trying
>> to argue for the sake of argument: I do agree with you that Go favors
>> composition over inheritance. And I do agree that inheritance based OOP
>> prioritizes type-hierarchies.
>>
>>
>>> Maybe you disagree with Rob Pike who made statements quite similar to
>>> what I said regarding composition in his quote I given above?
>>>
>>
>> If we are making an appeal to authority, I thnik you'll find he made
>> statements that directly contradict the ones I quoted above as disagree
>> with. And he made statements that support the ones I agree with.
>>
>>
>>> That's ridiculous. There is a question in FAQ. And answer you are aware
>>> of, which says Go is not OOP, which Rop Pike for sure aware of as well. And
>>> his wording in that video means not how you trying to interpret.
>>>
>>
>> His verbatim quote is "Go is a profoundly object oriented language.
>> Arguably more object oriented than say Java or C++". That clearly
>> contradicts your statement that Go is not an OOP language. He also goes to
>> great length to say that Go does not have inheritance (in favor of
>> composition), which, together with the first one, clearly implies that he
>> is contradicting your assertion that "OOP is all about inheritance".
>>
>> I don't see a lot of room for interpretation here.
>>
>> > But either way, if you don't mind me asking: What exactly does any of
>>> this have to do with generics?
>>> Good question, ask Alex Besogonov, because he started this arguing that
>>> Go has classes (opponent meant he doesn't want making Go like C++/Java).
>>>
>>
>> If we are pointing fingers, the statement he reacted to was "The real
>> value for Go is it's simplicity, avoidance of generics and avoidance of
>> classes", not "I don't want to make Go like C++/Java". And Alex put his
>> statement into parenthesis, 

Re: [go-nuts] Re: Generics, please go away!

[Space A.]

Ok I see you change a little bit your position, so I only comment on this:

> His verbatim quote is "Go is a profoundly object oriented language.
Arguably more object oriented than say Java or C++". That clearly
contradicts your statement that Go is not an OOP language. He also goes to
great length to say that Go does not have inheritance (in favor of
composition), which, together with the first one, clearly implies that he
is contradicting your assertion that "OOP is all about inheritance".

> I don't see a lot of room for interpretation here.

Well, I do. I do believe if you truly think he meant "Go is OOP language"
and continue insisting you are wrong.

1. First of all I feel it's more rhetoric, it's same as "Less is
exponentially more", and "[Go] ... Arguably more object oriented than say
Java or C++ ". I believe if you think logically "less" could not be "more",
right, and you wouldn't insist on that? Same goes to the statement that Go
is more object oriented. What I think he meant was "Go has even better
compatibilities even for OOP because of composition" which also in line
with what I said that you can use ANY language to write OOP program.
2. There is FAQ question and answer, and I do believe Rob took part in
answering FAQ, and this one in particular.

Anyways as you said in the beginning of thread, Go is no a religion, Rob is
not Jesus, he is alive and he can explain his position if it makes any
sense. Maybe I'm wrong and don't understand something, that's possible. So
I'm not arguing for the sake of arguing.





пт, 1 янв. 2021 г. в 16:48, Axel Wagner :

> On Fri, Jan 1, 2021 at 1:57 PM Space A.  wrote:
>
>> > Javascript is an incredibly popular language with non-inheritance OOP.
>> Or, at least, no inheritance at the type-level (so either way, invalidating
>> your statement that OOP is about type-hierarchies).
>>
> This is debatable but JS is a non-OOP language.
>>
>
> That's certainly a valid opinion to hold. I don't believe it, empirically,
> agrees with the common wisdom around it, though.
>
>
>> And yet if you wonder, there is no definition of what OOP language is.
>> Give it any, I don't mind. But it seems to most of us it's quite clear (by
>> major examples like C++ or Java) until we start arguing just for arguing.
>>
>
> With this, I agree. Note, again, that it doesn't actually *matter* for the
> question of whether or not Go should get generics, whether we call it an
> OOP language or not. And yet, it has become a point of argument in this
> thread - AFAICT, purely for the sake of arguing.
>
> > Repetition does not make a false statement true. Instead of copy-pasting
>> yourself, it would be prudent to cite sources. For example, is there any
>> text book that agrees with your definition of OOP?
>> What exactly you disagree on? I will copy and paste once again for your
>> convenience =)
>>
>
> There really is no need (though I recognize what you are trying to do).
> Let me quote a couple of your statements that I disagree with:
> • "Go doesn't have classes and is not an OOP language."
> • "Oh my... It is pure sophistic nonsense. OOP is all about inheritance.
> Not just whether you have "objects" in a language spec or not."
> • "As I said, OOP (if we talk about language, not a program written in OOP
> paradigm, because you can use ANY language for that) is all about
> inheritance."
>
> And in the interest of clarity and to illustrate that I'm not just trying
> to argue for the sake of argument: I do agree with you that Go favors
> composition over inheritance. And I do agree that inheritance based OOP
> prioritizes type-hierarchies.
>
>
>> Maybe you disagree with Rob Pike who made statements quite similar to
>> what I said regarding composition in his quote I given above?
>>
>
> If we are making an appeal to authority, I thnik you'll find he made
> statements that directly contradict the ones I quoted above as disagree
> with. And he made statements that support the ones I agree with.
>
>
>> That's ridiculous. There is a question in FAQ. And answer you are aware
>> of, which says Go is not OOP, which Rop Pike for sure aware of as well. And
>> his wording in that video means not how you trying to interpret.
>>
>
> His verbatim quote is "Go is a profoundly object oriented language.
> Arguably more object oriented than say Java or C++". That clearly
> contradicts your statement that Go is not an OOP language. He also goes to
> great length to say that Go does not have inheritance (in favor of
> composition), which, together with the first one, clearly implies that he
> is contradicting your assertion that "OOP is all about inheritance".
>
> I don't see a lot of room for interpretation here.
>
> > But either way, if you don't mind me asking: What exactly does any of
>> this have to do with generics?
>> Good question, ask Alex Besogonov, because he started this arguing that
>> Go has classes (opponent meant he doesn't want making Go like C++/Java).
>>
>
> If we are pointing fingers, the 

Re: [go-nuts] Re: Generics, please go away!

['Axel Wagner' via golang-nuts]

On Fri, Jan 1, 2021 at 1:57 PM Space A.  wrote:

> > Javascript is an incredibly popular language with non-inheritance OOP.
> Or, at least, no inheritance at the type-level (so either way, invalidating
> your statement that OOP is about type-hierarchies).
>
This is debatable but JS is a non-OOP language.
>

That's certainly a valid opinion to hold. I don't believe it, empirically,
agrees with the common wisdom around it, though.


> And yet if you wonder, there is no definition of what OOP language is.
> Give it any, I don't mind. But it seems to most of us it's quite clear (by
> major examples like C++ or Java) until we start arguing just for arguing.
>

With this, I agree. Note, again, that it doesn't actually *matter* for the
question of whether or not Go should get generics, whether we call it an
OOP language or not. And yet, it has become a point of argument in this
thread - AFAICT, purely for the sake of arguing.

> Repetition does not make a false statement true. Instead of copy-pasting
> yourself, it would be prudent to cite sources. For example, is there any
> text book that agrees with your definition of OOP?
> What exactly you disagree on? I will copy and paste once again for your
> convenience =)
>

There really is no need (though I recognize what you are trying to do). Let
me quote a couple of your statements that I disagree with:
• "Go doesn't have classes and is not an OOP language."
• "Oh my... It is pure sophistic nonsense. OOP is all about inheritance.
Not just whether you have "objects" in a language spec or not."
• "As I said, OOP (if we talk about language, not a program written in OOP
paradigm, because you can use ANY language for that) is all about
inheritance."

And in the interest of clarity and to illustrate that I'm not just trying
to argue for the sake of argument: I do agree with you that Go favors
composition over inheritance. And I do agree that inheritance based OOP
prioritizes type-hierarchies.


> Maybe you disagree with Rob Pike who made statements quite similar to what
> I said regarding composition in his quote I given above?
>

If we are making an appeal to authority, I thnik you'll find he made
statements that directly contradict the ones I quoted above as disagree
with. And he made statements that support the ones I agree with.


> That's ridiculous. There is a question in FAQ. And answer you are aware
> of, which says Go is not OOP, which Rop Pike for sure aware of as well. And
> his wording in that video means not how you trying to interpret.
>

His verbatim quote is "Go is a profoundly object oriented language.
Arguably more object oriented than say Java or C++". That clearly
contradicts your statement that Go is not an OOP language. He also goes to
great length to say that Go does not have inheritance (in favor of
composition), which, together with the first one, clearly implies that he
is contradicting your assertion that "OOP is all about inheritance".

I don't see a lot of room for interpretation here.

> But either way, if you don't mind me asking: What exactly does any of
> this have to do with generics?
> Good question, ask Alex Besogonov, because he started this arguing that Go
> has classes (opponent meant he doesn't want making Go like C++/Java).
>

If we are pointing fingers, the statement he reacted to was "The real value
for Go is it's simplicity, avoidance of generics and avoidance of classes",
not "I don't want to make Go like C++/Java". And Alex put his statement
into parenthesis, clearly indicating that he considers it only a minor
side-point.

But, if we agree it doesn't matter, we should probably just drop it.



>
>
>
>
> пт, 1 янв. 2021 г. в 05:16, Axel Wagner :
>
>> On Fri, Jan 1, 2021 at 1:23 AM Space A.  wrote:
>>
>>> > Sorry to disappoint you (actually, no, not sorry) but OOP has nothing
>>> to do with inheritance. It's a common feature in object-oriented
>>> programming but it's not essential.
>>> > Moreover, Go has inheritance as well (struct embedding and interface
>>> inheritance), making it a fairly typical example. The only significant
>>> difference is that Go has structural typing, instead of manually
>>> declaration of implemented interfaces.
>>>
>>> You don't disappoint me by repeating wrong statements.
>>>
>>> As I said, OOP (if we talk about language, not a program written in OOP
>>> paradigm, because you can use ANY language for that) is all about
>>> inheritance. Period. Proof - take any major OOP language and see how it's
>>> done, what's in its heart.
>>>
>>
>> Javascript is an incredibly popular language with non-inheritance OOP.
>> Or, at least, no inheritance at the type-level (so either way, invalidating
>> your statement that OOP is about type-hierarchies).
>>
>> Secondly, and I copy-paste myself here:
>>> Classes (like in Java) vs structs (like in Go) is about inheritance vs
>>> composition, not about attaching fields and methods. Inheritance implies
>>> type hierarchy, child and parent, virtual functions, abstract 

Re: [go-nuts] Re: Generics, please go away!

[Space A.]

> Javascript is an incredibly popular language with non-inheritance OOP.
Or, at least, no inheritance at the type-level (so either way, invalidating
your statement that OOP is about type-hierarchies).
This is debatable but JS is a non-OOP language. And yet if you wonder,
there is no definition of what OOP language is. Give it any, I don't mind.
But it seems to most of us it's quite clear (by major examples like C++ or
Java) until we start arguing just for arguing.

> Repetition does not make a false statement true. Instead of copy-pasting
yourself, it would be prudent to cite sources. For example, is there any
text book that agrees with your definition of OOP?
What exactly you disagree on? I will copy and paste once again for your
convenience =)
Classes (like in Java) vs structs (like in Go) is about inheritance vs
composition, not about attaching fields and methods. Inheritance implies
type hierarchy, child and parent, virtual functions, abstract and final
implementations and so on so forth to keep this all of this manageable.

You disagree on a statement that composition is not inheritance? Or that
inheritance implies type hierarchy and vise versa? Maybe you disagree with
Rob Pike who made statements quite similar to what I said regarding
composition in his quote I given above? Or just arguing for arguing? I just
don't understand your pathos here.

> One thing that is conspicuously absent from this quote, of course, is the
term "Object oriented programming" (or even just "Object"). FTR, if you
quote Rob Pike, you should also be aware that he has always staunchly
defended the stance that Go is an OOP language:
That's ridiculous. There is a question in FAQ. And answer you are aware of,
which says Go is not OOP, which Rop Pike for sure aware of as well. And his
wording in that video means not how you trying to interpret.

> But either way, if you don't mind me asking: What exactly does any of
this have to do with generics?
Good question, ask Alex Besogonov, because he started this arguing that Go
has classes (opponent meant he doesn't want making Go like C++/Java).




пт, 1 янв. 2021 г. в 05:16, Axel Wagner :

> On Fri, Jan 1, 2021 at 1:23 AM Space A.  wrote:
>
>> > Sorry to disappoint you (actually, no, not sorry) but OOP has nothing
>> to do with inheritance. It's a common feature in object-oriented
>> programming but it's not essential.
>> > Moreover, Go has inheritance as well (struct embedding and interface
>> inheritance), making it a fairly typical example. The only significant
>> difference is that Go has structural typing, instead of manually
>> declaration of implemented interfaces.
>>
>> You don't disappoint me by repeating wrong statements.
>>
>> As I said, OOP (if we talk about language, not a program written in OOP
>> paradigm, because you can use ANY language for that) is all about
>> inheritance. Period. Proof - take any major OOP language and see how it's
>> done, what's in its heart.
>>
>
> Javascript is an incredibly popular language with non-inheritance OOP. Or,
> at least, no inheritance at the type-level (so either way, invalidating
> your statement that OOP is about type-hierarchies).
>
> Secondly, and I copy-paste myself here:
>> Classes (like in Java) vs structs (like in Go) is about inheritance vs
>> composition, not about attaching fields and methods. Inheritance implies
>> type hierarchy, child and parent, virtual functions, abstract and final
>> implementations and so on so forth to keep this all of this manageable.
>>
>
> Repetition does not make a false statement true. Instead of copy-pasting
> yourself, it would be prudent to cite sources. For example, is there any
> text book that agrees with your definition of OOP?
>
> If you don't understand what it means, please study a little bit (with all
>> respect and blabla, I also learn all the time). Because these two
>> approaches are different.
>>
>> Here is some small quote and link which I think can help:
>>
>> My late friend Alain Fournier once told me that he considered the lowest
>>> form of academic work to be taxonomy. And you know what? Type hierarchies
>>> are just taxonomy. You need to decide what piece goes in what box, every
>>> type's parent, whether A inherits from B or B from A.  Is a sortable array
>>> an array that sorts or a sorter represented by an array? If you believe
>>> that types address all design issues you must make that decision.
>>>
>> I believe that's a preposterous way to think about programming. What
>>> matters isn't the ancestor relations between things but what they can do
>>> for you.
>>>
>>> That, of course, is where interfaces come into Go. But they're part of a
>>> bigger picture, the true Go philosophy.
>>> If C++ and Java are about type hierarchies and the taxonomy of types, Go
>>> is about composition.
>>> Doug McIlroy, the eventual inventor of Unix pipes, wrote in 1964 (!):
>>>
>>> We should have some ways of coupling programs like garden hose--screw in
>>> another segment when it 

Re: [go-nuts] Re: Generics, please go away!

['Axel Wagner' via golang-nuts]

On Fri, Jan 1, 2021 at 1:23 AM Space A.  wrote:

> > Sorry to disappoint you (actually, no, not sorry) but OOP has nothing to
> do with inheritance. It's a common feature in object-oriented programming
> but it's not essential.
> > Moreover, Go has inheritance as well (struct embedding and interface
> inheritance), making it a fairly typical example. The only significant
> difference is that Go has structural typing, instead of manually
> declaration of implemented interfaces.
>
> You don't disappoint me by repeating wrong statements.
>
> As I said, OOP (if we talk about language, not a program written in OOP
> paradigm, because you can use ANY language for that) is all about
> inheritance. Period. Proof - take any major OOP language and see how it's
> done, what's in its heart.
>

Javascript is an incredibly popular language with non-inheritance OOP. Or,
at least, no inheritance at the type-level (so either way, invalidating
your statement that OOP is about type-hierarchies).

Secondly, and I copy-paste myself here:
> Classes (like in Java) vs structs (like in Go) is about inheritance vs
> composition, not about attaching fields and methods. Inheritance implies
> type hierarchy, child and parent, virtual functions, abstract and final
> implementations and so on so forth to keep this all of this manageable.
>

Repetition does not make a false statement true. Instead of copy-pasting
yourself, it would be prudent to cite sources. For example, is there any
text book that agrees with your definition of OOP?

If you don't understand what it means, please study a little bit (with all
> respect and blabla, I also learn all the time). Because these two
> approaches are different.
>
> Here is some small quote and link which I think can help:
>
> My late friend Alain Fournier once told me that he considered the lowest
>> form of academic work to be taxonomy. And you know what? Type hierarchies
>> are just taxonomy. You need to decide what piece goes in what box, every
>> type's parent, whether A inherits from B or B from A.  Is a sortable array
>> an array that sorts or a sorter represented by an array? If you believe
>> that types address all design issues you must make that decision.
>>
> I believe that's a preposterous way to think about programming. What
>> matters isn't the ancestor relations between things but what they can do
>> for you.
>>
>> That, of course, is where interfaces come into Go. But they're part of a
>> bigger picture, the true Go philosophy.
>> If C++ and Java are about type hierarchies and the taxonomy of types, Go
>> is about composition.
>> Doug McIlroy, the eventual inventor of Unix pipes, wrote in 1964 (!):
>>
>> We should have some ways of coupling programs like garden hose--screw in
>> another segment when it becomes necessary to massage data in another way.
>> This is the way of IO also.
>>
>> That is the way of Go also. Go takes that idea and pushes it very far. It
>> is a language of composition and coupling.
>> The obvious example is the way interfaces give us the composition of
>> components. It doesn't matter what that thing is, if it implements method M
>> I can just drop it in here.
>> Another important example is how concurrency gives us the composition of
>> independently executing computations.
>> And there's even an unusual (and very simple) form of type composition:
>> embedding.
>> These compositional techniques are what give Go its flavor, which is
>> profoundly different from the flavor of C++ or Java programs.
>>
>
One thing that is conspicuously absent from this quote, of course, is the
term "Object oriented programming" (or even just "Object"). FTR, if you
quote Rob Pike, you should also be aware that he has always staunchly
defended the stance that Go is an OOP language:
https://www.youtube.com/watch?t=750=rKnDgT73v8s

But either way, if you don't mind me asking: What exactly does any of this
have to do with generics?


> https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html
>
>
>
>
>
> чт, 31 дек. 2020 г. в 23:27, Alex Besogonov :
>
>> On Wednesday, December 30, 2020 at 12:23:35 PM UTC-8 Space A. wrote:
>>
>>> > OOP isn't specific about how inheritance is handled (or if it is even
>>> supported)
>>> Oh my... It is pure sophistic nonsense. OOP is all about inheritance.
>>> Not just whether you have "objects" in a language spec or not.
>>>
>> Sorry to disappoint you (actually, no, not sorry) but OOP has nothing to
>> do with inheritance. It's a common feature in object-oriented programming
>> but it's not essential.
>>
>> Moreover, Go has inheritance as well (struct embedding and interface
>> inheritance), making it a fairly typical example. The only significant
>> difference is that Go has structural typing, instead of manually
>> declaration of implemented interfaces.
>>
>> > But on the topic of generics, this entire thread seems alarmist.
>>> Generics will open a huge door for libraries to be written that will make
>>> our lives easier.  I'm 

Re: [go-nuts] Re: Generics, please go away!

[Space A.]

> Sorry to disappoint you (actually, no, not sorry) but OOP has nothing to
do with inheritance. It's a common feature in object-oriented programming
but it's not essential.
> Moreover, Go has inheritance as well (struct embedding and interface
inheritance), making it a fairly typical example. The only significant
difference is that Go has structural typing, instead of manually
declaration of implemented interfaces.

You don't disappoint me by repeating wrong statements.

As I said, OOP (if we talk about language, not a program written in OOP
paradigm, because you can use ANY language for that) is all about
inheritance. Period. Proof - take any major OOP language and see how it's
done, what's in its heart.

Secondly, and I copy-paste myself here:
Classes (like in Java) vs structs (like in Go) is about inheritance vs
composition, not about attaching fields and methods. Inheritance implies
type hierarchy, child and parent, virtual functions, abstract and final
implementations and so on so forth to keep this all of this manageable.

If you don't understand what it means, please study a little bit (with all
respect and blabla, I also learn all the time). Because these two
approaches are different.

Here is some small quote and link which I think can help:

My late friend Alain Fournier once told me that he considered the lowest
> form of academic work to be taxonomy. And you know what? Type hierarchies
> are just taxonomy. You need to decide what piece goes in what box, every
> type's parent, whether A inherits from B or B from A.  Is a sortable array
> an array that sorts or a sorter represented by an array? If you believe
> that types address all design issues you must make that decision.
>
I believe that's a preposterous way to think about programming. What
> matters isn't the ancestor relations between things but what they can do
> for you.
>
> That, of course, is where interfaces come into Go. But they're part of a
> bigger picture, the true Go philosophy.
> If C++ and Java are about type hierarchies and the taxonomy of types, Go
> is about composition.
> Doug McIlroy, the eventual inventor of Unix pipes, wrote in 1964 (!):
>
> We should have some ways of coupling programs like garden hose--screw in
> another segment when it becomes necessary to massage data in another way.
> This is the way of IO also.
>
> That is the way of Go also. Go takes that idea and pushes it very far. It
> is a language of composition and coupling.
> The obvious example is the way interfaces give us the composition of
> components. It doesn't matter what that thing is, if it implements method M
> I can just drop it in here.
> Another important example is how concurrency gives us the composition of
> independently executing computations.
> And there's even an unusual (and very simple) form of type composition:
> embedding.
> These compositional techniques are what give Go its flavor, which is
> profoundly different from the flavor of C++ or Java programs.
>

https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html





чт, 31 дек. 2020 г. в 23:27, Alex Besogonov :

> On Wednesday, December 30, 2020 at 12:23:35 PM UTC-8 Space A. wrote:
>
>> > OOP isn't specific about how inheritance is handled (or if it is even
>> supported)
>> Oh my... It is pure sophistic nonsense. OOP is all about inheritance. Not
>> just whether you have "objects" in a language spec or not.
>>
> Sorry to disappoint you (actually, no, not sorry) but OOP has nothing to
> do with inheritance. It's a common feature in object-oriented programming
> but it's not essential.
>
> Moreover, Go has inheritance as well (struct embedding and interface
> inheritance), making it a fairly typical example. The only significant
> difference is that Go has structural typing, instead of manually
> declaration of implemented interfaces.
>
> > But on the topic of generics, this entire thread seems alarmist.
>> Generics will open a huge door for libraries to be written that will make
>> our lives easier.  I'm thinking specifically about data processing and
>> machine learning.  A lot of devs use Python right now for this which leads
>> to duplication of code across languages.  Complex algorithms will be able
>> to be shared without hacky type conversions wrapping every function call.
>> Who is "yours"? You talk about Python so just go ahead and use Python if
>> it serves you, convince your team that Python is better, whatever.
>>
> You know that this argument can be applied to you as well?
>
>
>> среда, 30 декабря 2020 г. в 22:46:12 UTC+3, nichol...@gmail.com:
>>
>>> OOP isn't specific about how inheritance is handled (or if it is even
>>> supported).  The basic definition is objects with fields and methods, and
>>> being able to address the itself (typically using 'this' or 'self', but Go
>>> is unique in that you define what to call the object).  It does composition
>>> differently than most languages, but the functional needs are met.
>>>
>>> But on the topic of 

Re: [go-nuts] Re: Generics, please go away!

['Axel Wagner' via golang-nuts]

On Thu, Dec 31, 2020 at 9:27 PM Alex Besogonov 
wrote:

> Moreover, Go has inheritance as well (struct embedding and interface
> inheritance), making it a fairly typical example.
>

Interfaces yes (though I would use "subtyping", not "inheritance", but
potato tomato), but struct embedding, no. Embedding a type doesn't make a
struct usable as that type, so it's not subtyping (and notably, methods are
still called on the embedded type).

You're still correct that Go has subtyping though, yes :)


> The only significant difference is that Go has structural typing, instead
> of manually declaration of implemented interfaces.
>
> > But on the topic of generics, this entire thread seems alarmist.
>> Generics will open a huge door for libraries to be written that will make
>> our lives easier.  I'm thinking specifically about data processing and
>> machine learning.  A lot of devs use Python right now for this which leads
>> to duplication of code across languages.  Complex algorithms will be able
>> to be shared without hacky type conversions wrapping every function call.
>> Who is "yours"? You talk about Python so just go ahead and use Python if
>> it serves you, convince your team that Python is better, whatever.
>>
> You know that this argument can be applied to you as well?
>
>
>> среда, 30 декабря 2020 г. в 22:46:12 UTC+3, nichol...@gmail.com:
>>
>>> OOP isn't specific about how inheritance is handled (or if it is even
>>> supported).  The basic definition is objects with fields and methods, and
>>> being able to address the itself (typically using 'this' or 'self', but Go
>>> is unique in that you define what to call the object).  It does composition
>>> differently than most languages, but the functional needs are met.
>>>
>>> But on the topic of generics, this entire thread seems alarmist.
>>> Generics will open a huge door for libraries to be written that will make
>>> our lives easier.  I'm thinking specifically about data processing and
>>> machine learning.  A lot of devs use Python right now for this which leads
>>> to duplication of code across languages.  Complex algorithms will be able
>>> to be shared without hacky type conversions wrapping every function call.
>>> We'll be able to use things like trees as simply as we use maps or slices.
>>> I don't think we'll see the language turn into the grossness that is Java
>>> or C++ because of it.
>>>
>>> On Wednesday, December 30, 2020 at 4:27:15 AM UTC-8 Space A. wrote:
>>>
 Go doesn't have classes and is not an OOP language.

 Classes (like in Java) vs structs (like in Go) is about inheritance vs
 composition, not about attaching fields and methods. Inheritance implies
 type hierarchy, child and parent, virtual functions, abstract and final
 implementations and so on so forth to keep this all of this manageable.



 вторник, 29 декабря 2020 г. в 23:27:45 UTC+3, Alex Besogonov:

> Please, stop being so condescending to newcomers and non-professional
> developers. Generics as uses by end-users will improve their experience,
> not make it harder.
>
> (And what is this obsession with "classes"? Go has them - structs with
> methods are classes).
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/7b58c437-4507-4d75-b0a2-de7b0ba8b58dn%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHeNF_ZtZEEUqNaNFPGX3TzH1jPC0FTeKXMmJ006Sa_qQ%40mail.gmail.com.

Re: [go-nuts] Re: Generics, please go away!

['Axel Wagner' via golang-nuts]

Hi,

On Wed, Dec 30, 2020 at 8:16 PM Jeremy French  wrote:

> This discussion bears a lot of similarity to the argument about
> inheritance, and Go solved that issue rather elegantly with interfaces -
> describe the behavior you need instead of the types you'll accept. I'm
> wondering if there's a way to do the same thing with this problem.


I'm confused by this sentence, because the rest of your message seems to
describe Generics. Perhaps a different way to define constraints, but the
base mechanic of "enable a function to specify a set of types that might be
used and work generally over them" seems to be implied by what you write.
And that's what I would call "generics".

(FTR, BTW: Interfaces don't really solve the same problem set as
inheritance would. Embedding is intended to address the same problem as
inheritance, though. Interfaces are rather intended to solve a subset of
the problems generics solve as well, namely have one function work with a
variety of different types)

As I understand the proposal right now (and honestly, I don't understand it
> fully, and that's part of the issue)
>

I think it's important to remember that the generics design draft is
intended to fully discuss the design, including edge-cases, implementation
issues, how it would address different use-cases, open questions and
possible answers. It's not intended as teaching material or specification.

Personally, I would expect the actual specification of the design to be
around as long and around as complex as the "Properties of types and
values" section in the spec - perhaps a bit longer, perhaps a bit shorter
https://golang.org/ref/spec#Properties_of_types_and_values

a function signature can either say "I will only accept a value with type
> X" or "I will accept a value with any type."
>

Not quite. Functions can already do this. It's that they can accept *types*
(not values). And they can specify an (possibly empty) interface the type
must implement, or a list of types that might be used (or both).


> Could there be another option? In Ian's reversing example, could the
> function signature say "I will accept an integer or a string, (but not a
> struct or a map)"?
>

Yes, the design supports this already (though, FTR, for that particular
function you really want it to work over *any* slice type, no matter what
the element type is).


> Or even better - Is there a way for the function signature to say, "I will
> accept any type that can be compared as greater-than or less-than"? This
> feels very Go-y.
>

This will also be possible, using a new `constraints` package (or similar).
That is, there will be a `constraints.Ordered` and similar for this purpose.

That way, by looking at the signature, you know what the function is going
> to try to be doing with it. But you also get the benefit of not having to
> write and maintain two essentially identical pieces of code that differ
> only by their type.
>

> This is less than half an idea, because I don't know exactly how you would
> do that. I'm hoping this thought will spur creativity in someone else.
> Maybe there could be some built in "generics" (using this term in a
> different way) like "Comparable" or "Addable" or "Sortable" or something,
> and you could use those keywords as a type in your function signature, but
> under the covers, the compiler would determine whether the value's type
> conforms. That's not a great idea, but maybe someone can improve on it?
>
> Or could there be something similar to interfaces, where a property (or
> set of properties) could be required instead of a set of methods? Could
> built-in primitive types have properties added as Comparable or Addable or
> something? Again, this solution feels clunky and not the right answer, but
> it feels like there's a great solution somewhere in this direction.
>
> On Wed, Dec 30, 2020, 8:37 AM Vivi  wrote:
>
>> I'm sure my thought is off-topic and is not applicable, I shall give a
>> try after seeing the trends in programming and non-programming world. There
>> is an "overlap" between Generic and non-Generic. If it can be solve between
>> the two sides, that's easy with "translation" to and back?
>>
>> When we have a language barrier, Google Translator makes that possible or
>> ignore everything I said here.
>> When Go can cross-compile to different OS architectures, it could be
>> applicable for source code as well.
>>
>> On Wednesday, 30 December 2020 at 20:27:15 UTC+8 Space A. wrote:
>>
>>> Go doesn't have classes and is not an OOP language.
>>>
>>> Classes (like in Java) vs structs (like in Go) is about inheritance vs
>>> composition, not about attaching fields and methods. Inheritance implies
>>> type hierarchy, child and parent, virtual functions, abstract and final
>>> implementations and so on so forth to keep this all of this manageable.
>>>
>>>
>>>
>>> вторник, 29 декабря 2020 г. в 23:27:45 UTC+3, Alex Besogonov:
>>>
 Please, stop being so condescending to newcomers and non-professional

Re: [go-nuts] Re: Generics, please go away!

[Jeremy French]

This conversation makes me want to consider whether there's a way to solve
the problem that Generics solves, but solve it in a different way. This
discussion bears a lot of similarity to the argument about inheritance, and
Go solved that issue rather elegantly with interfaces - describe the
behavior you need instead of the types you'll accept. I'm wondering if
there's a way to do the same thing with this problem. As I understand the
proposal right now (and honestly, I don't understand it fully, and that's
part of the issue) a function signature can either say "I will only accept
a value with type X" or "I will accept a value with any type."  Could there
be another option? In Ian's reversing example, could the function signature
say "I will accept an integer or a string, (but not a struct or a map)"?
Or even better - Is there a way for the function signature to say, "I will
accept any type that can be compared as greater-than or less-than"? This
feels very Go-y. That way, by looking at the signature, you know what the
function is going to try to be doing with it. But you also get the benefit
of not having to write and maintain two essentially identical pieces of
code that differ only by their type.

This is less than half an idea, because I don't know exactly how you would
do that. I'm hoping this thought will spur creativity in someone else.
Maybe there could be some built in "generics" (using this term in a
different way) like "Comparable" or "Addable" or "Sortable" or something,
and you could use those keywords as a type in your function signature, but
under the covers, the compiler would determine whether the value's type
conforms. That's not a great idea, but maybe someone can improve on it?

Or could there be something similar to interfaces, where a property (or set
of properties) could be required instead of a set of methods? Could
built-in primitive types have properties added as Comparable or Addable or
something? Again, this solution feels clunky and not the right answer, but
it feels like there's a great solution somewhere in this direction.

On Wed, Dec 30, 2020, 8:37 AM Vivi  wrote:

> I'm sure my thought is off-topic and is not applicable, I shall give a try
> after seeing the trends in programming and non-programming world. There is
> an "overlap" between Generic and non-Generic. If it can be solve between
> the two sides, that's easy with "translation" to and back?
>
> When we have a language barrier, Google Translator makes that possible or
> ignore everything I said here.
> When Go can cross-compile to different OS architectures, it could be
> applicable for source code as well.
>
> On Wednesday, 30 December 2020 at 20:27:15 UTC+8 Space A. wrote:
>
>> Go doesn't have classes and is not an OOP language.
>>
>> Classes (like in Java) vs structs (like in Go) is about inheritance vs
>> composition, not about attaching fields and methods. Inheritance implies
>> type hierarchy, child and parent, virtual functions, abstract and final
>> implementations and so on so forth to keep this all of this manageable.
>>
>>
>>
>> вторник, 29 декабря 2020 г. в 23:27:45 UTC+3, Alex Besogonov:
>>
>>> Please, stop being so condescending to newcomers and non-professional
>>> developers. Generics as uses by end-users will improve their experience,
>>> not make it harder.
>>>
>>> (And what is this obsession with "classes"? Go has them - structs with
>>> methods are classes).
>>>
>>> On Tuesday, December 29, 2020 at 1:32:30 AM UTC-8
>>> rickti...@googlemail.com wrote:
>>>
 My point of view is that Generics should not become part of the Go
 standard library. I appreciate there are use cases where it is very helpful
 to have, but I do not believe that adds value to Go. The real value for Go
 is it's simplicity, avoidance of generics and avoidance of classes. This
 makes the language accessible and approachable to all, which is
 increasingly more valuable. Go appeals to new-comers and experienced
 developers because it is simple, and comfortable. The rate of uptake in
 computing technology is still subject to Moores law, and today we see a new
 type of programmer emerging, the 'citizen developer'.

 Go follows time proven computational concepts, it does not follow the
 'new paradigm' tribes, it's roots are firmly planted in statically typed
 procedural/functional programming techniques, and this maps well to much of
 the literature available. The growth of entry level developers ( aka
 'citizen developers' ) will be exponential over the next decade, and in
 that landscape it is Go's simplicity that will win the day.

 On Monday, 28 December 2020 at 17:35:40 UTC L Godioleskky wrote:

> " If generics gets added to Go, we're opening a very dangerous door,
> and
> it will be the downfall of Go because - and Robert Griesemer this is
> especially addressed to you - what's next then? Seriously, what's
> next? ... "
>
> .. 

Re: [go-nuts] Re: Generics, please go away!

[Jan Mercl]

On Tue, Dec 29, 2020 at 5:01 PM L Godioleskky  wrote:

> Hopefully the GO leadership will isolate Generics to a module so that those 
> who dont wish to use them can quietly ignore them, while those that believe 
> Generics have value can just import the relevant module(s)

It's a language change, not some new/additional stdlib package.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-UUUkEFe5NWKKLtopOFMwa1enLWRRtPsG764PVtYfijkQ%40mail.gmail.com.

Re: [go-nuts] Re: Generics, please go away!

[Henrik Johansson]

Who said anything about gold standards?
This is about generics going away and I would argue that many if not all
computer languages that have generics also have a user base that is
overwhelmingly in favor of it compared to it not existing. Perhaps another
flavor of generics would be better but being without it would be worse.

On Sat, 26 Dec 2020, 16:13 Jeremy French,  wrote:

> If Java and C++ were the perfection of computer language evolution, then
> there would be no need for Go. Using your predecessors as the gold standard
> makes no sense, because if they were, then no other iteration would be
> necessary. We wouldn't be having this discussion, because there would be no
> Go.
>
> Java and C++ both suffer from being complex enough that both inital
> development and especially further maintenance of code written in those
> languages is slower than it should be. This was one of the main drivers in
> creating Go in the first place (as I understand it).
>
> Trying to make all programming languages identical means that all but one
> of them is redundant.
>
> On Fri, Dec 25, 2020, 11:49 AM Henrik Johansson 
> wrote:
>
>> Ok maybe this thread has gone on too long.
>> Both Java and C++ has benefited greatly from generics and most of their
>> respective communities wouldn't want them gone. I am pretty sure that's
>> what will happen with Go as well. Can we leave it now before we go from
>> "corruption" to whatever hyperbole is next?
>>
>> On Fri, 25 Dec 2020, 14:10 redsto...@gmail.com, 
>> wrote:
>>
>>> Yes, I agree with you. I use go for more than 3 years. The language is
>>> simple and elegant. But generics will destroy this. Generics bring a lot of
>>> complexity, make language seems ugly with only a few benifit.  They say you
>>> can ignore it. Infact you can not. This language is on the way of
>>> corruption.
>>>
>>> On Monday, December 21, 2020 at 3:38:54 AM UTC+8 Martin Hanson wrote:
>>>
 I think people who want generics added to Go should go and program in
 Java or C++.

 Adding generics to Go will ruin the beautiful simplicity of the
 language and I haven't found a single example in which adding generics to
 Go pays off.

 Even with the examples of having two almost identical functions reverse
 some list, one of ints and one of strings, seriously!? We already have tons
 and tons of open source reusable code that covers all use cases which
 people complain about.

 Go was designed without generics purposefully from the start and Go is
 fine just the way it is.

 Adding generics means that we're opening the door to the beginning of
 bloating Go with all the crap that Java, C++ and all the other complex
 languages has gotten over the years, and Go was designed specifically
 without that clutter. So we add generics, then what? Classes?

 Adding generics to Go ruins that beautiful simplicity that went into
 the design and the added complexity just isn't worth it! The standard
 library have managed just fine without generics and so have we!

>>> --
>>> 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.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/7c3e4e9f-4553-413b-8bdb-57d316ad030cn%40googlegroups.com
>>> 
>>> .
>>>
>> --
>> 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/LEEuJPOg0oo/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CAKOF6940G995GFLoNp_z1Hsx2G_2e%2Bibs7xAqkTne0RAJUL5fw%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKOF697Q2SaL-grQiL81gUkTztjJc_cF5r3JKhjO%2B1FPtAitAw%40mail.gmail.com.

Re: [go-nuts] Re: Generics, please go away!

[Jeremy French]

If Java and C++ were the perfection of computer language evolution, then
there would be no need for Go. Using your predecessors as the gold standard
makes no sense, because if they were, then no other iteration would be
necessary. We wouldn't be having this discussion, because there would be no
Go.

Java and C++ both suffer from being complex enough that both inital
development and especially further maintenance of code written in those
languages is slower than it should be. This was one of the main drivers in
creating Go in the first place (as I understand it).

Trying to make all programming languages identical means that all but one
of them is redundant.

On Fri, Dec 25, 2020, 11:49 AM Henrik Johansson 
wrote:

> Ok maybe this thread has gone on too long.
> Both Java and C++ has benefited greatly from generics and most of their
> respective communities wouldn't want them gone. I am pretty sure that's
> what will happen with Go as well. Can we leave it now before we go from
> "corruption" to whatever hyperbole is next?
>
> On Fri, 25 Dec 2020, 14:10 redsto...@gmail.com, 
> wrote:
>
>> Yes, I agree with you. I use go for more than 3 years. The language is
>> simple and elegant. But generics will destroy this. Generics bring a lot of
>> complexity, make language seems ugly with only a few benifit.  They say you
>> can ignore it. Infact you can not. This language is on the way of
>> corruption.
>>
>> On Monday, December 21, 2020 at 3:38:54 AM UTC+8 Martin Hanson wrote:
>>
>>> I think people who want generics added to Go should go and program in
>>> Java or C++.
>>>
>>> Adding generics to Go will ruin the beautiful simplicity of the language
>>> and I haven't found a single example in which adding generics to Go pays
>>> off.
>>>
>>> Even with the examples of having two almost identical functions reverse
>>> some list, one of ints and one of strings, seriously!? We already have tons
>>> and tons of open source reusable code that covers all use cases which
>>> people complain about.
>>>
>>> Go was designed without generics purposefully from the start and Go is
>>> fine just the way it is.
>>>
>>> Adding generics means that we're opening the door to the beginning of
>>> bloating Go with all the crap that Java, C++ and all the other complex
>>> languages has gotten over the years, and Go was designed specifically
>>> without that clutter. So we add generics, then what? Classes?
>>>
>>> Adding generics to Go ruins that beautiful simplicity that went into the
>>> design and the added complexity just isn't worth it! The standard library
>>> have managed just fine without generics and so have we!
>>>
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/7c3e4e9f-4553-413b-8bdb-57d316ad030cn%40googlegroups.com
>> 
>> .
>>
> --
> 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/LEEuJPOg0oo/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAKOF6940G995GFLoNp_z1Hsx2G_2e%2Bibs7xAqkTne0RAJUL5fw%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2Bj6mhCP5F8qv1NJMKX0a8onY%3Dt12TuZ5J-wSq7%2BLOzqWOQmUw%40mail.gmail.com.

Re: [go-nuts] Re: Generics, please go away!

[Christian Staffa]

I would rather have a survey with generics specific question that would shed a 
better light to this topic. at least now, after following this discussion. i 
also think that it could be good to add it but is it worth when it also adds 
complexity? then i would say no thank you. go is powerful and simple but after 
that it would be powerful and complex. i think it would be better for go to 
solve the error handling. this would also make the go code better readable 
which would help the language more than adding generics if it is a good 
solution, i think  

Sent from my iPhone

> On 26. Dec 2020, at 03:32, redsto...@gmail.com  wrote:
> 
> 25% of  the survey takers answered the question means 75% of the survey 
> takers think there is no need to and any features in the language. This is a 
> common mistake of SURVIVOR BIAS.
> 
>> On Wednesday, December 23, 2020 at 4:49:48 AM UTC+8 Ian Lance Taylor wrote:
>> On Tue, Dec 22, 2020 at 1:24 AM Markus Heukelom 
>>  wrote: 
>> > 
>> > Why not issue a poll on generics, was this ever done? (I could've missed 
>> > it, I am only following Go ~2 years). While the community has a vote in 
>> > accepting/rejecting the current generics proposal, the community was never 
>> > (really) asked if generics is desired in the first place and especially 
>> > what the scope of generics should be. Is that correct? 
>> 
>> I don't know of a poll specifically about generics. But for the past 
>> several years we've done a Go community survey, and every year there 
>> is significant support for adding generics to the language. For 
>> example, although the results of the 2020 survey haven't been 
>> assembled yet, you can see the results of the 2019 survey at 
>> https://blog.golang.org/survey2019-results. In that survey when asked 
>> "Which critical language features do you need that are not available 
>> in Go?", 25% of the survey takers answered the question, and of those 
>> 79% mentioned generics. Previous years also showed support for adding 
>> generics. Of course this isn't definitive, since there was no clear 
>> way for people they say that do not want generics. But it's also not 
>> definitive in a different direction, which is that by and large people 
>> who don't currently use Go didn't take the survey, and probably some 
>> of them would also want generics. 
>> 
>> So while Go is not and never has been a poll-driven language, I think 
>> it's reasonable to say that there is real support for adding generics. 
>> 
>> 
>> > Another thought: there are many popular, type-safe programming language 
>> > with generics already. So if you really need generics, there's plenty to 
>> > pick from. There's not that many without, I can only name Go and C. So if 
>> > generics is added to Go there's far less choice to pick a modern type-safe 
>> > language that doesn't have generics. It's a feature that makes Go quite 
>> > special. 
>> 
>> Actually, C does have generics, through the preprocessor macro 
>> mechanism. It's difficult to write, but it does provide the same kind 
>> of functionality that would be available in Go if we added generics. 
>> For example, here is a compile-time-type-safe vector implementation in 
>> C: 
>> 
>> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/vec.h;h=cb871124ce2241402af05e4697a5e28904c462fb;hb=HEAD
>>  
>> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/vec.c;h=85274c4e00c202e680761cef516bd17bb58b6261;hb=HEAD
>>  
>> 
>> Ian 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/4402ee72-1720-4110-bebf-849b60863039n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/BF592BDE-839E-42C2-9415-512D81D4535F%40gmail.com.

Re: [go-nuts] Re: Generics, please go away!

[redsto...@gmail.com]

25% of  the survey takers answered the question means 75% of the survey 
takers think there is no need to and any features in the language. This is 
a common mistake of SURVIVOR BIAS.

On Wednesday, December 23, 2020 at 4:49:48 AM UTC+8 Ian Lance Taylor wrote:

> On Tue, Dec 22, 2020 at 1:24 AM Markus Heukelom
>  wrote:
> >
> > Why not issue a poll on generics, was this ever done? (I could've missed 
> it, I am only following Go ~2 years). While the community has a vote in 
> accepting/rejecting the current generics proposal, the community was never 
> (really) asked if generics is desired in the first place and especially 
> what the scope of generics should be. Is that correct?
>
> I don't know of a poll specifically about generics. But for the past
> several years we've done a Go community survey, and every year there
> is significant support for adding generics to the language. For
> example, although the results of the 2020 survey haven't been
> assembled yet, you can see the results of the 2019 survey at
> https://blog.golang.org/survey2019-results. In that survey when asked
> "Which critical language features do you need that are not available
> in Go?", 25% of the survey takers answered the question, and of those
> 79% mentioned generics. Previous years also showed support for adding
> generics. Of course this isn't definitive, since there was no clear
> way for people they say that do not want generics. But it's also not
> definitive in a different direction, which is that by and large people
> who don't currently use Go didn't take the survey, and probably some
> of them would also want generics.
>
> So while Go is not and never has been a poll-driven language, I think
> it's reasonable to say that there is real support for adding generics.
>
>
> > Another thought: there are many popular, type-safe programming language 
> with generics already. So if you really need generics, there's plenty to 
> pick from. There's not that many without, I can only name Go and C. So if 
> generics is added to Go there's far less choice to pick a modern type-safe 
> language that doesn't have generics. It's a feature that makes Go quite 
> special.
>
> Actually, C does have generics, through the preprocessor macro
> mechanism. It's difficult to write, but it does provide the same kind
> of functionality that would be available in Go if we added generics.
> For example, here is a compile-time-type-safe vector implementation in
> C:
>
>
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/vec.h;h=cb871124ce2241402af05e4697a5e28904c462fb;hb=HEAD
>
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/vec.c;h=85274c4e00c202e680761cef516bd17bb58b6261;hb=HEAD
>
> Ian
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4402ee72-1720-4110-bebf-849b60863039n%40googlegroups.com.

Re: [go-nuts] Re: Generics, please go away!

[Wojciech S. Czarnecki]

Dnia 2020-12-25, o godz. 11:28:54
"Space A."  napisał(a):

> What a ridiculous bullshit.

Please keep discussion here civilized.
This is not a proper place for name-calling and expletives.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20201225210239.6f88485d%40xmint.

Re: [go-nuts] Re: Generics, please go away!

[Space A.]

What a ridiculous bullshit.

пятница, 25 декабря 2020 г. в 19:49:26 UTC+3, Henrik Johansson: 

> Ok maybe this thread has gone on too long.
> Both Java and C++ has benefited greatly from generics and most of their 
> respective communities wouldn't want them gone. I am pretty sure that's 
> what will happen with Go as well. Can we leave it now before we go from 
> "corruption" to whatever hyperbole is next?
>
> On Fri, 25 Dec 2020, 14:10 redsto...@gmail.com,  
> wrote:
>
>> Yes, I agree with you. I use go for more than 3 years. The language is 
>> simple and elegant. But generics will destroy this. Generics bring a lot of 
>> complexity, make language seems ugly with only a few benifit.  They say you 
>> can ignore it. Infact you can not. This language is on the way of  
>> corruption.
>>
>> On Monday, December 21, 2020 at 3:38:54 AM UTC+8 Martin Hanson wrote:
>>
>>> I think people who want generics added to Go should go and program in 
>>> Java or C++. 
>>>
>>> Adding generics to Go will ruin the beautiful simplicity of the language 
>>> and I haven't found a single example in which adding generics to Go pays 
>>> off. 
>>>
>>> Even with the examples of having two almost identical functions reverse 
>>> some list, one of ints and one of strings, seriously!? We already have tons 
>>> and tons of open source reusable code that covers all use cases which 
>>> people complain about. 
>>>
>>> Go was designed without generics purposefully from the start and Go is 
>>> fine just the way it is. 
>>>
>>> Adding generics means that we're opening the door to the beginning of 
>>> bloating Go with all the crap that Java, C++ and all the other complex 
>>> languages has gotten over the years, and Go was designed specifically 
>>> without that clutter. So we add generics, then what? Classes? 
>>>
>>> Adding generics to Go ruins that beautiful simplicity that went into the 
>>> design and the added complexity just isn't worth it! The standard library 
>>> have managed just fine without generics and so have we! 
>>>
>> -- 
>> 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.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/7c3e4e9f-4553-413b-8bdb-57d316ad030cn%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b02e918a-a1a6-405f-ab65-814206056b5fn%40googlegroups.com.

Re: [go-nuts] Re: Generics, please go away!

[Henrik Johansson]

Ok maybe this thread has gone on too long.
Both Java and C++ has benefited greatly from generics and most of their
respective communities wouldn't want them gone. I am pretty sure that's
what will happen with Go as well. Can we leave it now before we go from
"corruption" to whatever hyperbole is next?

On Fri, 25 Dec 2020, 14:10 redsto...@gmail.com, 
wrote:

> Yes, I agree with you. I use go for more than 3 years. The language is
> simple and elegant. But generics will destroy this. Generics bring a lot of
> complexity, make language seems ugly with only a few benifit.  They say you
> can ignore it. Infact you can not. This language is on the way of
> corruption.
>
> On Monday, December 21, 2020 at 3:38:54 AM UTC+8 Martin Hanson wrote:
>
>> I think people who want generics added to Go should go and program in
>> Java or C++.
>>
>> Adding generics to Go will ruin the beautiful simplicity of the language
>> and I haven't found a single example in which adding generics to Go pays
>> off.
>>
>> Even with the examples of having two almost identical functions reverse
>> some list, one of ints and one of strings, seriously!? We already have tons
>> and tons of open source reusable code that covers all use cases which
>> people complain about.
>>
>> Go was designed without generics purposefully from the start and Go is
>> fine just the way it is.
>>
>> Adding generics means that we're opening the door to the beginning of
>> bloating Go with all the crap that Java, C++ and all the other complex
>> languages has gotten over the years, and Go was designed specifically
>> without that clutter. So we add generics, then what? Classes?
>>
>> Adding generics to Go ruins that beautiful simplicity that went into the
>> design and the added complexity just isn't worth it! The standard library
>> have managed just fine without generics and so have we!
>>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/7c3e4e9f-4553-413b-8bdb-57d316ad030cn%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKOF6940G995GFLoNp_z1Hsx2G_2e%2Bibs7xAqkTne0RAJUL5fw%40mail.gmail.com.

Re: [go-nuts] Re: Generics, please go away!

[Anthony Martin]

> Tasteless attempt at humour.

Our collective taste is ruined by the
anosmia of a contemporary disease.

  Anthony

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/X%2BV/BLNZHFkjTaCt%40alice.

Re: [go-nuts] Re: Generics, please go away!

[Space A.]

 > Personally, though, I must say that the generics discussion has been 
going on for 10 years (and even more, if we don't limit ourselves to Go) 
and I don't - personally - believe that there is much hidden cost or 
surprising benefit left to be discovered. 

There is nothing hidden and nothing new! Lol. We know for 100% what will 
happen, all the beauty and simplicity of Go will be lost in one moment, and 
ecosystem will be poisoned forever. And YES, after such a huge change to 
the language, who knows what will be added next. In fact it doesn't matter 
what exactly, because Go was the only language resistant to all of this. 
Until now.

среда, 23 декабря 2020 г. в 16:14:38 UTC+3, axel.wa...@googlemail.com: 

> On Wed, Dec 23, 2020 at 1:17 PM Martin Hanson  
> wrote:
>
>> @Ian, for more than 10 years we have managed nicely without generics.
>>
>
> Of course, this doesn't answer how we'd have managed *with* them.
>
> We did manage for decades without general purpose CPUs. We did manage for 
> several decades without functions, coroutines or hashtables. We did manage 
> for decades without portable programming languages or multi-tasking 
> operating systems. We managed for many decades without the internet or the 
> world wide web.
>
> In hindsight, though,  "we managed so long without them" doesn't appear to 
> be a very convincing argument to not have them today.
>  
>
>> So what is the real true-life problems that validates adding generics
>> to Go? I haven't seen a single example, seriously not one! I have only
>> seen useless examples like the one Ian gives in the talk, which of
>> course I know only serves as an example, but we need real life problems
>> to solve, not theoretical ones.
>>
>
> To me, this suggests that the issue isn't that you haven't seen enough 
> examples, but that you haven't found them convincing you that the benefits 
> outweigh the costs. Which is a completely valid position to take. 
> Obviously, lots of other people (at least some of which you, I think, 
> respect professionally) see that differently. Which is also completely 
> valid. So, confronted with that reality, there are many productive ways to 
> react. Some examples are
>
> • Try to engage in the design process to keep the cost down (i.e. suggest 
> simplifications to the generics design)
> • Try to engage in the design process to increase the benefits (i.e. 
> suggest improvements that increase its power)
> • Accept that it's possible for reasonable people to look at the same 
> problem and proposed solution and agree on what the costs and what the 
> benefits are, but weigh them differently, just as a matter of personal 
> taste or opinion - and thus agree to disagree
> • Try to change the other persons mind about what the costs or benefits 
> are and how much they weigh
>
> Now, that last one *can* be very productive. Especially early on in a 
> discussion, we tend to overlook hidden costs or surprising benefits and 
> having them pointed out can be really helpful. Personally, though, I must 
> say that the generics discussion has been going on for 10 years (and even 
> more, if we don't limit ourselves to Go) and I don't - personally - believe 
> that there is much hidden cost or surprising benefit left to be discovered. 
> And ISTM that swaying someone's mind on them will most likely take more 
> than just outright saying that you don't agree.
>
> So, I guess the question really is, what's the goal? Do you want to get 
> the best language? In that case, I'd personally suggest to focus on 
> improving the generics design. Or do you want to convince others that their 
> valuation of costs and benefits is inaccurate? In that case, I'd personally 
> suggest to try and find new costs or benefits - but keep in mind, that 10 
> years is a lot of time for a lot of them to already have been mentioned a 
> lot. Or do you just want to be heard as being in disagreement? That's also, 
> of course, valid.
>
> What I understand from all of this is that people who are pro-generics are
>> in reality really talking about something that is *nice to have*, not
>> something that is seriously needed and this is where I become really
>> frustrated!
>
>
> I understand this frustration. But it might help to keep in mind that 
> computers are simply nice to have in exactly the same way.
> And I think there's an opportunity to have empathy with people who *are* 
> in favor of generics. Because just like you are frustrated that generics 
> are just nice to have (i.e. you perceive their actual benefit as 
> insignificant), people on the other side of the aisle might be *just as* 
> frustrated by you, because generics are just slightly more complex (i.e. 
> they perceive their actual costs as insignificant). Your frustration is 
> valid, but so is theirs.
>
> As I have said many times now, adding stuff to Go comes with
>> a heavy price, it opens the door for all the people who have been whining
>> and complaining about Go for the past ten+ 

Re: [go-nuts] Re: Generics, please go away!

[Space A.]

Prime driver of Java's success were enterprises with huge amount of 
investments (money) into ecosystem along with all JSRs developed by 
companies and groups with J2EE becoming de-facto a standard for building 
enterprise applications. And all this was happening way before any generics.

среда, 23 декабря 2020 г. в 16:43:46 UTC+3, ren...@ix.netcom.com: 

> To add some weight to the pro generic side - from someone who doesn’t 
> necessarily think Go needs them - generics and more specifically the “Java 
> Collections” package was a prime driver in Java’s success. Moving highly 
> tuned and verified implementations into the core library removed a huge 
> burden on developers - allowing them to focus more time on application 
> structure/function rather than nuts and bolts - while gaining greater 
> “readability” as these apps used common/well known apis as a foundation. 
>
> On Dec 23, 2020, at 7:14 AM, 'Axel Wagner' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
> 
>
> On Wed, Dec 23, 2020 at 1:17 PM Martin Hanson  
> wrote:
>
>> @Ian, for more than 10 years we have managed nicely without generics.
>>
>
> Of course, this doesn't answer how we'd have managed *with* them.
>
> We did manage for decades without general purpose CPUs. We did manage for 
> several decades without functions, coroutines or hashtables. We did manage 
> for decades without portable programming languages or multi-tasking 
> operating systems. We managed for many decades without the internet or the 
> world wide web.
>
> In hindsight, though,  "we managed so long without them" doesn't appear to 
> be a very convincing argument to not have them today.
>  
>
>> So what is the real true-life problems that validates adding generics
>> to Go? I haven't seen a single example, seriously not one! I have only
>> seen useless examples like the one Ian gives in the talk, which of
>> course I know only serves as an example, but we need real life problems
>> to solve, not theoretical ones.
>>
>
> To me, this suggests that the issue isn't that you haven't seen enough 
> examples, but that you haven't found them convincing you that the benefits 
> outweigh the costs. Which is a completely valid position to take. 
> Obviously, lots of other people (at least some of which you, I think, 
> respect professionally) see that differently. Which is also completely 
> valid. So, confronted with that reality, there are many productive ways to 
> react. Some examples are
>
> • Try to engage in the design process to keep the cost down (i.e. suggest 
> simplifications to the generics design)
> • Try to engage in the design process to increase the benefits (i.e. 
> suggest improvements that increase its power)
> • Accept that it's possible for reasonable people to look at the same 
> problem and proposed solution and agree on what the costs and what the 
> benefits are, but weigh them differently, just as a matter of personal 
> taste or opinion - and thus agree to disagree
> • Try to change the other persons mind about what the costs or benefits 
> are and how much they weigh
>
> Now, that last one *can* be very productive. Especially early on in a 
> discussion, we tend to overlook hidden costs or surprising benefits and 
> having them pointed out can be really helpful. Personally, though, I must 
> say that the generics discussion has been going on for 10 years (and even 
> more, if we don't limit ourselves to Go) and I don't - personally - believe 
> that there is much hidden cost or surprising benefit left to be discovered. 
> And ISTM that swaying someone's mind on them will most likely take more 
> than just outright saying that you don't agree.
>
> So, I guess the question really is, what's the goal? Do you want to get 
> the best language? In that case, I'd personally suggest to focus on 
> improving the generics design. Or do you want to convince others that their 
> valuation of costs and benefits is inaccurate? In that case, I'd personally 
> suggest to try and find new costs or benefits - but keep in mind, that 10 
> years is a lot of time for a lot of them to already have been mentioned a 
> lot. Or do you just want to be heard as being in disagreement? That's also, 
> of course, valid.
>
> What I understand from all of this is that people who are pro-generics are
>> in reality really talking about something that is *nice to have*, not
>> something that is seriously needed and this is where I become really
>> frustrated!
>
>
> I understand this frustration. But it might help to keep in mind that 
> computers are simply nice to have in exactly the same way.
> And I think there's an opportunity to have empathy with people who *are* 
> in favor of generics. Because just like you are frustrated that generics 
> are just nice to have (i.e. you perceive their actual benefit as 
> insignificant), people on the other side of the aisle might be *just as* 
> frustrated by you, because generics are just slightly more complex (i.e. 
> they perceive 

Re: [go-nuts] Re: Generics, please go away!

[Robert Engels]

To add some weight to the pro generic side - from someone who doesn’t 
necessarily think Go needs them - generics and more specifically the “Java 
Collections” package was a prime driver in Java’s success. Moving highly tuned 
and verified implementations into the core library removed a huge burden on 
developers - allowing them to focus more time on application structure/function 
rather than nuts and bolts - while gaining greater “readability” as these apps 
used common/well known apis as a foundation. 

> On Dec 23, 2020, at 7:14 AM, 'Axel Wagner' via golang-nuts 
>  wrote:
> 
> 
>> On Wed, Dec 23, 2020 at 1:17 PM Martin Hanson  
>> wrote:
> 
>> @Ian, for more than 10 years we have managed nicely without generics.
> 
> Of course, this doesn't answer how we'd have managed *with* them.
> 
> We did manage for decades without general purpose CPUs. We did manage for 
> several decades without functions, coroutines or hashtables. We did manage 
> for decades without portable programming languages or multi-tasking operating 
> systems. We managed for many decades without the internet or the world wide 
> web.
> 
> In hindsight, though,  "we managed so long without them" doesn't appear to be 
> a very convincing argument to not have them today.
>  
>> So what is the real true-life problems that validates adding generics
>> to Go? I haven't seen a single example, seriously not one! I have only
>> seen useless examples like the one Ian gives in the talk, which of
>> course I know only serves as an example, but we need real life problems
>> to solve, not theoretical ones.
> 
> To me, this suggests that the issue isn't that you haven't seen enough 
> examples, but that you haven't found them convincing you that the benefits 
> outweigh the costs. Which is a completely valid position to take. Obviously, 
> lots of other people (at least some of which you, I think, respect 
> professionally) see that differently. Which is also completely valid. So, 
> confronted with that reality, there are many productive ways to react. Some 
> examples are
> 
> • Try to engage in the design process to keep the cost down (i.e. suggest 
> simplifications to the generics design)
> • Try to engage in the design process to increase the benefits (i.e. suggest 
> improvements that increase its power)
> • Accept that it's possible for reasonable people to look at the same problem 
> and proposed solution and agree on what the costs and what the benefits are, 
> but weigh them differently, just as a matter of personal taste or opinion - 
> and thus agree to disagree
> • Try to change the other persons mind about what the costs or benefits are 
> and how much they weigh
> 
> Now, that last one *can* be very productive. Especially early on in a 
> discussion, we tend to overlook hidden costs or surprising benefits and 
> having them pointed out can be really helpful. Personally, though, I must say 
> that the generics discussion has been going on for 10 years (and even more, 
> if we don't limit ourselves to Go) and I don't - personally - believe that 
> there is much hidden cost or surprising benefit left to be discovered. And 
> ISTM that swaying someone's mind on them will most likely take more than just 
> outright saying that you don't agree.
> 
> So, I guess the question really is, what's the goal? Do you want to get the 
> best language? In that case, I'd personally suggest to focus on improving the 
> generics design. Or do you want to convince others that their valuation of 
> costs and benefits is inaccurate? In that case, I'd personally suggest to try 
> and find new costs or benefits - but keep in mind, that 10 years is a lot of 
> time for a lot of them to already have been mentioned a lot. Or do you just 
> want to be heard as being in disagreement? That's also, of course, valid.
> 
>> What I understand from all of this is that people who are pro-generics are
>> in reality really talking about something that is *nice to have*, not
>> something that is seriously needed and this is where I become really
>> frustrated!
> 
> I understand this frustration. But it might help to keep in mind that 
> computers are simply nice to have in exactly the same way.
> And I think there's an opportunity to have empathy with people who *are* in 
> favor of generics. Because just like you are frustrated that generics are 
> just nice to have (i.e. you perceive their actual benefit as insignificant), 
> people on the other side of the aisle might be *just as* frustrated by you, 
> because generics are just slightly more complex (i.e. they perceive their 
> actual costs as insignificant). Your frustration is valid, but so is theirs.
> 
>> As I have said many times now, adding stuff to Go comes with
>> a heavy price, it opens the door for all the people who have been whining
>> and complaining about Go for the past ten+ years to add further stuff that
>> is "nice to have", or change things they keep complaining about, like how
>> Go handles errors 

Re: [go-nuts] Re: Generics, please go away!

['Axel Wagner' via golang-nuts]

On Wed, Dec 23, 2020 at 1:17 PM Martin Hanson 
wrote:

> @Ian, for more than 10 years we have managed nicely without generics.
>

Of course, this doesn't answer how we'd have managed *with* them.

We did manage for decades without general purpose CPUs. We did manage for
several decades without functions, coroutines or hashtables. We did manage
for decades without portable programming languages or multi-tasking
operating systems. We managed for many decades without the internet or the
world wide web.

In hindsight, though,  "we managed so long without them" doesn't appear to
be a very convincing argument to not have them today.


> So what is the real true-life problems that validates adding generics
> to Go? I haven't seen a single example, seriously not one! I have only
> seen useless examples like the one Ian gives in the talk, which of
> course I know only serves as an example, but we need real life problems
> to solve, not theoretical ones.
>

To me, this suggests that the issue isn't that you haven't seen enough
examples, but that you haven't found them convincing you that the benefits
outweigh the costs. Which is a completely valid position to take.
Obviously, lots of other people (at least some of which you, I think,
respect professionally) see that differently. Which is also completely
valid. So, confronted with that reality, there are many productive ways to
react. Some examples are

• Try to engage in the design process to keep the cost down (i.e. suggest
simplifications to the generics design)
• Try to engage in the design process to increase the benefits (i.e.
suggest improvements that increase its power)
• Accept that it's possible for reasonable people to look at the same
problem and proposed solution and agree on what the costs and what the
benefits are, but weigh them differently, just as a matter of personal
taste or opinion - and thus agree to disagree
• Try to change the other persons mind about what the costs or benefits are
and how much they weigh

Now, that last one *can* be very productive. Especially early on in a
discussion, we tend to overlook hidden costs or surprising benefits and
having them pointed out can be really helpful. Personally, though, I must
say that the generics discussion has been going on for 10 years (and even
more, if we don't limit ourselves to Go) and I don't - personally - believe
that there is much hidden cost or surprising benefit left to be discovered.
And ISTM that swaying someone's mind on them will most likely take more
than just outright saying that you don't agree.

So, I guess the question really is, what's the goal? Do you want to get the
best language? In that case, I'd personally suggest to focus on improving
the generics design. Or do you want to convince others that their valuation
of costs and benefits is inaccurate? In that case, I'd personally suggest
to try and find new costs or benefits - but keep in mind, that 10 years is
a lot of time for a lot of them to already have been mentioned a lot. Or do
you just want to be heard as being in disagreement? That's also, of course,
valid.

What I understand from all of this is that people who are pro-generics are
> in reality really talking about something that is *nice to have*, not
> something that is seriously needed and this is where I become really
> frustrated!


I understand this frustration. But it might help to keep in mind that
computers are simply nice to have in exactly the same way.
And I think there's an opportunity to have empathy with people who *are* in
favor of generics. Because just like you are frustrated that generics are
just nice to have (i.e. you perceive their actual benefit as
insignificant), people on the other side of the aisle might be *just as*
frustrated by you, because generics are just slightly more complex (i.e.
they perceive their actual costs as insignificant). Your frustration is
valid, but so is theirs.

As I have said many times now, adding stuff to Go comes with
> a heavy price, it opens the door for all the people who have been whining
> and complaining about Go for the past ten+ years to add further stuff that
> is "nice to have", or change things they keep complaining about, like how
> Go handles errors and what not.
>
> After generics gets added, it's going to be something else next time, and
> again and again. The list goes on and on about changes people want to
> make to Go. Not real life problems, just so-called "nice to have".
>
> No, the added and increased complexity I have witness in other
> programming languages over the past 3-4 decades, because of exactly
> things like this, is absolutely mind blowing. This must not happen to Go!
>
> --
> 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.
> To view this discussion on the web visit
> 

Re: [go-nuts] Re: Generics, please go away!

[K. Alex Mills]

On Wed, Dec 23, 2020, 6:17 AM Martin Hanson 
wrote:

>
> After generics gets added, it's going to be something else next time, and
> again and again. The list goes on and on about changes people want to
> make to Go. Not real life problems, just so-called "nice to have".
>
> No, the added and increased complexity I have witness in other
> programming languages over the past 3-4 decades, because of exactly
> things like this, is absolutely mind blowing. This must not happen to Go!


Given that generics was among the very first language changes proposed and
the first official prototype has only arrived 10 years later, I don't think
Go is in danger of adding new features at a breakneck pace out of a
misguided sense of what might be convenient. To date, the language
designers have been extraordinarily careful and measured in any decision to
add new language features. I would be surprised if this attitude changed in
the future as a result of including generics.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALJzkY8kexq%3DYL9FQt1HBY59W9D4WwnAJVn%2B%2BZ3phtcjamAxPg%40mail.gmail.com.

Re: [go-nuts] Re: Generics, please go away!

[Kevin Chadwick]

On 12/23/20 11:19 AM, Axel Wagner wrote:
> I have to call it out here though as I see statistic abuse on the news 
> every
> day. Not to mention that asking the question encourages people to think of
> something.
> 
> Ignoring that encouragement in the question (and not remembering survey
> structure). This would more accurately be described as 80% reported not 
> needing
> any new features and 15% reported needing Generics!
> 
> 
> That re-framing is itself abuse of statistics. Because (as rightly pointed out
> by Ian)
> 
>> Of course this isn't definitive, since there was no clear way for people they
> say that do not want generics.
> 
> Unless there was a "I don't need any new features" checkbox, exactly 0% of
> respondents reported not needing any new features.
> There not being such a checkbox might be considered a methodological flaw. But
> luckily, the goal was neither to do science, nor to vote, so it doesn't hugely
> matter.
> 
> I think what how Ian phrased it, is unambiguously the most accurate 
> description:
> 25% of the survey takers answered that question and of those, 79% mentioned
> generics. Any inaccuracies come from reading more meaning into these numbers -
> as you tried when saying "80% reported not needing any new features" or as 
> would
> happen if Go *was* designed based on public polls and these numbers would be
> used to say generics where desperately needed. But it isn't and the survey 
> isn't
> the (only) reason to include generics and Ian was quite careful in pointing 
> out
> the methodological flaws in trying to interpret the numbers in any of these
> ways, so there is nothing to see here :)

I disagree on multiple counts. Most importantly, I misleadingly state "more
accurately" and not accurately described in order to emphasize that the
impression given by the statement may be the complete opposite to reality.

Primarily. It misled me to the wrong conclusion at first. You can argue, that is
my problem, but it isn't. It is framing, though I am sure not intentionally.

An accurate statement might be, "it is the most requested new feature, when
asked"? Of course that assumes new features are good, which is part of the
debate raised in this thread.



On a side note, generics may alleviate some confusion around interfaces and
maybe type safety (I avoid interfaces in my code) and may prove to be a good or
bad thing to happen to Go for me. Unfortunately, I am not sure a survey would
help anyway. Personally, I have found the discussions confusing and haven't the
time or likely the expertise for any sufficient analysis. Perhaps many have but
I doubt that?

I have never used Generics and potentially never will. Maybe I will learn to
love them. The likelihood is a love/hate relationship AFAICT.

Thankfully, Ian is very engaging on the details for those that can and seems to
be very knowledgeable and considerate on the topic. I am glad I don't have those
pressures, too.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a7ced0ab-a7de-c48c-3ce1-9424405cf50c%40gmail.com.

Re: [go-nuts] Re: Generics, please go away!

[Space A.]

I didn't take part in few of the last surveys. However I filled that very 
last one and haven't seen any generics-related questions. It was also 
stated somewhere that some of them randomized? So I answered a lot of weird 
questions for anything, but language features. Anyways if Go is not 
poll-driven it doesn't make any sense and couldn't be an argument. Result 
could be different if people knew that decision will be made out of that 
survey results. Another thing is that after the years of this generics hype 
train without any alternative point of view, a lot of public just convinced 
that it's fine. 


среда, 23 декабря 2020 г. в 14:20:24 UTC+3, axel.wa...@googlemail.com: 

> On Wed, Dec 23, 2020 at 11:42 AM Kevin Chadwick  wrote:
>
>> I have to call it out here though as I see statistic abuse on the news 
>> every
>> day. Not to mention that asking the question encourages people to think of
>> something.
>>
>> Ignoring that encouragement in the question (and not remembering survey
>> structure). This would more accurately be described as 80% reported not 
>> needing
>> any new features and 15% reported needing Generics!
>>
>
> That re-framing is itself abuse of statistics. Because (as rightly pointed 
> out by Ian)
>
> > Of course this isn't definitive, since there was no clear way for people 
> they say that do not want generics.
>
> Unless there was a "I don't need any new features" checkbox, exactly 0% of 
> respondents reported not needing any new features.
> There not being such a checkbox might be considered a methodological flaw. 
> But luckily, the goal was neither to do science, nor to vote, so it doesn't 
> hugely matter.
>
> I think what how Ian phrased it, is unambiguously the most accurate 
> description: 25% of the survey takers answered that question and of those, 
> 79% mentioned generics. Any inaccuracies come from reading more meaning 
> into these numbers - as you tried when saying "80% reported not needing any 
> new features" or as would happen if Go *was* designed based on public polls 
> and these numbers would be used to say generics where desperately needed. 
> But it isn't and the survey isn't the (only) reason to include generics and 
> Ian was quite careful in pointing out the methodological flaws in trying to 
> interpret the numbers in any of these ways, so there is nothing to see here 
> :)
>  
>
>>
>> -- 
>> 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.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/4ea1d4b4-6059-936e-5ad2-c7b4919eb369%40gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/96a1297f-fbe6-4aac-b577-30d6028d23edn%40googlegroups.com.

Re: [go-nuts] Re: Generics, please go away!

[Markus Heukelom]

On Tue, Dec 22, 2020 at 9:48 PM Ian Lance Taylor  wrote:

> On Tue, Dec 22, 2020 at 1:24 AM Markus Heukelom
>  wrote:
> >
> > Why not issue a poll on generics, was this ever done? (I could've missed
> it, I  am only following Go ~2 years). While the community has a vote in
> accepting/rejecting the current generics proposal, the community was never
> (really) asked if generics is desired in the first place and especially
> what the scope of generics should be. Is that correct?
>
> I don't know of a poll specifically about generics.  But for the past
> several years we've done a Go community survey, and every year there
> is significant support for adding generics to the language.  For
> example, although the results of the 2020 survey haven't been
> assembled yet, you can see the results of the 2019 survey at
> https://blog.golang.org/survey2019-results.  In that survey when asked
>



> "Which critical language features do you need that are not available
> in Go?", 25% of the survey takers answered the question, and of those
> 79% mentioned generics.  Previous years also showed support for adding
> generics.


Thanks for this, that's actually a lot higher than I would expect.

It could be of interest to see the percentage of people who answered
"generics" split by "years of any coding experience" and "years of go
experience" (graph 2 and 3 in the blog post).  It may be helpful in this
discussion for people to see if  their "peers" requested generics.

I am not against generics, it can definitely be useful in some cases,
although I too certainly worry quite a bit about the mess it can cause in
other languages. Generics is a great tool for over-engineering.


Of course this isn't definitive, since there was no clear
> way for people they say that do not want generics.  But it's also not
> definitive in a different direction, which is that by and large people
> who don't currently use Go didn't take the survey, and probably some
> of them would also want generics.
>
> So while Go is not and never has been a poll-driven language, I think
> it's reasonable to say that there is real support for adding generics.
>
>
> > Another thought:  there are many popular, type-safe programming language
> with generics already. So if you really need generics, there's plenty to
> pick from. There's not that many  without, I can only name Go and C. So if
> generics is added to Go there's far less choice to pick a modern type-safe
> language that doesn't have generics. It's a feature that makes Go quite
> special.
>
> Actually, C does have generics, through the preprocessor macro
>

mechanism.  It's difficult to write, but it does provide the same kind
> of functionality that would be available in Go if we added generics.

For example, here is a compile-time-type-safe vector implementation in
> C:
>
>
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/vec.h;h=cb871124ce2241402af05e4697a5e28904c462fb;hb=HEAD
>
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/vec.c;h=85274c4e00c202e680761cef516bd17bb58b6261;hb=HEAD
>
> Ian
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMoB8rWJ%3DaOYYruQoJBrKY5NPGQHPdQZ8wSV%2BHSKMPSLofUrnw%40mail.gmail.com.

Re: [go-nuts] Re: Generics, please go away!

['Axel Wagner' via golang-nuts]

On Wed, Dec 23, 2020 at 11:42 AM Kevin Chadwick  wrote:

> I have to call it out here though as I see statistic abuse on the news
> every
> day. Not to mention that asking the question encourages people to think of
> something.
>
> Ignoring that encouragement in the question (and not remembering survey
> structure). This would more accurately be described as 80% reported not
> needing
> any new features and 15% reported needing Generics!
>

That re-framing is itself abuse of statistics. Because (as rightly pointed
out by Ian)

> Of course this isn't definitive, since there was no clear way for people
they say that do not want generics.

Unless there was a "I don't need any new features" checkbox, exactly 0% of
respondents reported not needing any new features.
There not being such a checkbox might be considered a methodological flaw.
But luckily, the goal was neither to do science, nor to vote, so it doesn't
hugely matter.

I think what how Ian phrased it, is unambiguously the most accurate
description: 25% of the survey takers answered that question and of those,
79% mentioned generics. Any inaccuracies come from reading more meaning
into these numbers - as you tried when saying "80% reported not needing any
new features" or as would happen if Go *was* designed based on public polls
and these numbers would be used to say generics where desperately needed.
But it isn't and the survey isn't the (only) reason to include generics and
Ian was quite careful in pointing out the methodological flaws in trying to
interpret the numbers in any of these ways, so there is nothing to see here
:)


>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/4ea1d4b4-6059-936e-5ad2-c7b4919eb369%40gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHtLU0hyqt5sMi_U9VY0dzsaKhSBuHREKeDEMVz1G9gtA%40mail.gmail.com.

Re: [go-nuts] Re: Generics, please go away!

[Kevin Chadwick]

On 12/23/20 8:06 AM, Alex Besogonov wrote:
> In general, Go managed to tread a very fine line between "overcomplicated
> nonsense" and "stupidly verbose" pretty well. So I suggest trusting the 
> language
> maintainers. They are doing a great job!

I wholeheartedly agree with this and thank you for your dedication Ian and
others. You have the time to make a far better analysis than most/all of us?, in
any case.


> "Which critical language features do you need that are not available
> in Go?", 25% of the survey takers answered the question, and of those
> 79% mentioned generics. Previous years also showed support for adding
> generics.  Of course this isn't definitive,

I have to call it out here though as I see statistic abuse on the news every
day. Not to mention that asking the question encourages people to think of
something.

Ignoring that encouragement in the question (and not remembering survey
structure). This would more accurately be described as 80% reported not needing
any new features and 15% reported needing Generics!

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4ea1d4b4-6059-936e-5ad2-c7b4919eb369%40gmail.com.

Re: [go-nuts] Re: Generics, please go away!

[Robert Engels]

There are many shops that exclude using certain features (eg exceptions in 
C++). It makes interoperability and using 3rd party libs more difficult (plus 
other issues) but it can be done. 

> On Dec 22, 2020, at 9:41 PM, Jeremy French  wrote:
> 
> I'd like to second the notion that the argument "if you don't like them, 
> don't use them," is an invalid argument.  Anyone who's been in the game for 
> any length of time knows that more than we'd like, we're repairing someone 
> else's code, as opposed to writing our own from scratch.  If there is a bad 
> or confusing way to write Go code, then it will be written that way by some, 
> and we'll all be forced to deal with it.
> 
> It seems to me that part of the reason that Go was ever even a necessary 
> experiment was because these other languages were trying to appeal to as many 
> use cases as possible, and the complexity and awkwardness of those languages 
> - as well as their reliance on their programmers to know the "right way" to 
> write in the language - are an unavoidable consequence of succumbing to that 
> temptation. I would channel Antoine de Saint-Exupery in this: “Perfection is 
> Achieved Not When There Is Nothing More to Add, But When There Is Nothing 
> Left to Take Away” 
> 
> I also think saying "If you want a Java-like experience, use Java" is not 
> only not a personal attack, nor an exclusionary statement, it's a perfectly 
> reasonable recommendation. Programming languages are not exclusivity clubs 
> where if you use one, you're excluded from using another.  Using the right 
> tool for the job is part of our profession.  But I think some people, myself 
> included, find that easier to do when the tools don't all look and function 
> the same way.  Having a programming language that is simple, clear, fast, and 
> easy to maintain - even if it's considered not the right tool for the job in 
> every case - is something that I think holds value to us. That might not be 
> something that would be expressed very well in a survey.
> 
>> On Tuesday, December 22, 2020 at 6:57:47 PM UTC-5 ohir wrote:
>> 
>> Artur Vianna> you can keep writing your standard Go as it never existed. 
>> 
>> L Godioleskky> those of us who want to ignore them can easily do so 
>> 
>> Nope. You can neither pretend "it never existed" nor "ignore" no part of the 
>> language. 
>> You as a programmer are supposed to read and *understand* a lot of other's 
>> code 
>> before you will start to write your part. 
>> 
>> -- 
>> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/7e0e0b20-9646-43fa-a5ce-331f730c202cn%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/85157174-60EC-45EF-A27C-A2CD358B1049%40ix.netcom.com.

Re: [go-nuts] Re: Generics, please go away!

[Jeremy French]

I'd like to second the notion that the argument "if you don't like them, 
don't use them," is an invalid argument.  Anyone who's been in the game for 
any length of time knows that more than we'd like, we're repairing someone 
else's code, as opposed to writing our own from scratch.  If there is a bad 
or confusing way to write Go code, then it will be written that way by 
some, and we'll all be forced to deal with it.

It seems to me that part of the reason that Go was ever even a necessary 
experiment was because these other languages were trying to appeal to as 
many use cases as possible, and the complexity and awkwardness of those 
languages - as well as their reliance on their programmers to know the 
"right way" to write in the language - are an unavoidable consequence of 
succumbing to that temptation. I would channel Antoine de Saint-Exupery in 
this: “Perfection is Achieved Not When There Is Nothing More to Add, But 
When There Is Nothing Left to Take Away” 

I also think saying "If you want a Java-like experience, use Java" is not 
only not a personal attack, nor an exclusionary statement, it's a perfectly 
reasonable recommendation. Programming languages are not exclusivity clubs 
where if you use one, you're excluded from using another.  Using the right 
tool for the job is part of our profession.  But I think some people, 
myself included, find that easier to do when the tools don't all look and 
function the same way.  Having a programming language that is simple, 
clear, fast, and easy to maintain - even if it's considered not the right 
tool for the job in every case - is something that I think holds value to 
us. That might not be something that would be expressed very well in a 
survey.

On Tuesday, December 22, 2020 at 6:57:47 PM UTC-5 ohir wrote:

>
> Artur Vianna> you can keep writing your standard Go as it never existed.
>
> L Godioleskky> those of us who want to ignore them can easily do so 
>
> Nope. You can neither pretend "it never existed" nor "ignore" no part of 
> the language.
> You as a programmer are supposed to read and *understand* a lot of other's 
> code
> before you will start to write your part.
>
> -- 
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7e0e0b20-9646-43fa-a5ce-331f730c202cn%40googlegroups.com.

Re: [go-nuts] Re: Generics, please go away!

[Wojciech S. Czarnecki]

Artur Vianna> you can keep writing your standard Go as it never existed.

L Godioleskky> those of us who want to ignore them can easily do so 

Nope. You can neither pretend "it never existed" nor "ignore" no part of the 
language.
You as a programmer are supposed to read and *understand* a lot of other's code
before you will start to write your part.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20201223005655.5dfbd492%40xmint.

Re: [go-nuts] Re: Generics, please go away!

['Axel Wagner' via golang-nuts]

On Wed, Dec 23, 2020 at 12:19 AM Space A.  wrote:

> > Again, it bears repeating: "The Go designers where against generics" is
> historical fiction. "The Go team is succumbing to public pressure" is
> political fiction. Both are simply false. Anyone saying either of those
> either misunderstood something someone on the Go team said, or is repeating
> from someone else who misunderstood something.
>
> There is another possibility - you misunderstand something or someone and
> keep repeating that.
>

Sure. I might be wrong, I'm very willing to accept that possibility.
But "the Go designers where against generics" is an easily provable
statement - just find a quote saying that.

And just to pre-empt the obvious retort: Yes, I absolutely would prove my
side as well, but it's impossible to prove a negative - I can't prove that
there are no statements of that nature. There is at least some evidence
documenting what the official stance on generics has been, though:

• Ian provided an authoritative statement to that effect in this thread, as
far as he, personally is concerned
• There is this FAQ entry: https://golang.org/doc/faq#generics - it was
added two weeks before the open source release of Go, by Rob Pike, and
documents the stance "generics might be added, if we can make them work"
(which is notably different from "generics should not be in Go")
https://github.com/golang/go/commit/dd64f86e08
• Russ Cox earliest documented stance I have at hand is from a couple of
weeks *after* the open source release and it also is consistent with this
position: https://research.swtch.com/generic

I can probably come up with more sources if I really want to invest the
time. But I do feel confident that it is simply a well-documented fact,
that the statement has always been "Go might get generics, if we can figure
out a way to do it well". I am not aware of a single instance of anyone I
would consider a core Go designer that would contradict it.

How that stance was contorted into "the Go designers don't want generics"
or "Go will never have generics" is beyond me, even tough both of these
have been very persistently repeated throughout the years (the latter has
subsided a bit over the last two or three years, since it became apparent
that there is a seriously hopeful design on the way).

But, again: By all means, I'm more than willing to be proven wrong. I
haven't read everything any of them has ever said and I might very well
have missed something.


> среда, 23 декабря 2020 г. в 01:40:37 UTC+3, axel.wa...@googlemail.com:
>
>> On Tue, Dec 22, 2020 at 11:09 PM Martin Hanson 
>> wrote:
>>
>>> If you on the other hand is pro-generics to Go, then of course that is
>>> your right.
>>>
>>
>> Ian is on record, multiple times, as having argued in favor of generics
>> in Go long before its open source release and has since written many
>> proposals to add them - even before the Go community survey was a thing.
>>
>> Again, it bears repeating: "The Go designers where against generics" is
>> historical fiction. "The Go team is succumbing to public pressure" is
>> political fiction. Both are simply false. Anyone saying either of those
>> either misunderstood something someone on the Go team said, or is repeating
>> from someone else who misunderstood something.
>>
>> There are plenty of good reasons to criticize the addition of generics,
>> but neither of these is one.
>>
>> I for one doesn't hope that the future of Go is going to continue down
>>> this road, with new proposals for change popping up on GitHub every
>>> other day and surveys and possible outside pressure determining the
>>> future of Go. I would very much like to know if this is going to be the
>>> way it is.
>>
>> --
>>> 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.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/6452721608674913%40iva4-57c3b416b70c.qloud-c.yandex.net
>>> .
>>>
>> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/541a7371-7862-4e61-bfe9-0b7689916cc5n%40googlegroups.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.
To view this discussion on the web visit 

Re: [go-nuts] Re: Generics, please go away!

[Space A.]

> Again, it bears repeating: "The Go designers where against generics" is 
historical fiction. "The Go team is succumbing to public pressure" is 
political fiction. Both are simply false. Anyone saying either of those 
either misunderstood something someone on the Go team said, or is repeating 
from someone else who misunderstood something. 

There is another possibility - you misunderstand something or someone and 
keep repeating that.

среда, 23 декабря 2020 г. в 01:40:37 UTC+3, axel.wa...@googlemail.com: 

> On Tue, Dec 22, 2020 at 11:09 PM Martin Hanson  
> wrote:
>
>> If you on the other hand is pro-generics to Go, then of course that is
>> your right.
>>
>
> Ian is on record, multiple times, as having argued in favor of generics in 
> Go long before its open source release and has since written many proposals 
> to add them - even before the Go community survey was a thing.
>
> Again, it bears repeating: "The Go designers where against generics" is 
> historical fiction. "The Go team is succumbing to public pressure" is 
> political fiction. Both are simply false. Anyone saying either of those 
> either misunderstood something someone on the Go team said, or is repeating 
> from someone else who misunderstood something.
>
> There are plenty of good reasons to criticize the addition of generics, 
> but neither of these is one.
>
> I for one doesn't hope that the future of Go is going to continue down
>> this road, with new proposals for change popping up on GitHub every
>> other day and surveys and possible outside pressure determining the
>> future of Go. I would very much like to know if this is going to be the
>> way it is.
>
> -- 
>> 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.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/6452721608674913%40iva4-57c3b416b70c.qloud-c.yandex.net
>> .
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/541a7371-7862-4e61-bfe9-0b7689916cc5n%40googlegroups.com.

Re: [go-nuts] Re: Generics, please go away!

[Ian Lance Taylor]

On Tue, Dec 22, 2020 at 2:09 PM Martin Hanson
 wrote:
>
> @Ian, if you're succumbing to outside pressure, please don't.
>
> If you on the other hand is pro-generics to Go, then of course that is
> your right.
>
> I for one doesn't hope that the future of Go is going to continue down
> this road, with new proposals for change popping up on GitHub every
> other day and surveys and possible outside pressure determining the
> future of Go. I would very much like to know if this is going to be the
> way it is.

I am in favor of adding generics to Go if it can be done while
preserving the clarity and simplicity of the language.  See
https://blog.golang.org/why-generics (which I wrote).

I've been looking for ways to add generics to Go for a long time.  For
example, here is a proposal I wrote up in 2010:
https://go.googlesource.com/proposal/+/refs/heads/master/design/15292/2010-06-type-functions.md.
And that wasn't even the first one I wrote.  I hope they are at least
getting better over time.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXL6LwpwwQ84RYK88WotkNC57a8%3DBK32c1%3Dm-_zS_G7BA%40mail.gmail.com.

Re: [go-nuts] Re: Generics, please go away!

[Gerald Henriksen]

On Tue, 22 Dec 2020 22:56:32 +0100, you wrote:

>> He did explicitly said in the last paragraph that Go is not driven by
>> pools (aka surveys).
>
>Please re-read!
>
>The problem is that his post is quite contradictory. On the one hand he
>states that "Go is not and never has been a poll-driven language", yet
>at the same time, "I think it's reasonable to say that there is real
>support for adding generics" - because of the result of surveys!

No contradiction in the post.

He says clearly at the end that Go is not driven by polls

What he did do is show that the surverys do show support for the
inclusion of Generics, not that the surveys drove the decision to add
them.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/u9u4uftbaeeg2uduhrdhuutj9orfu6esp7%404ax.com.

Re: [go-nuts] Re: Generics, please go away!

[Ian Lance Taylor]

On Tue, Dec 22, 2020 at 1:57 PM Martin Hanson
 wrote:
>
> > He did explicitly said in the last paragraph that Go is not driven by
> > pools (aka surveys).
>
> Please re-read!
>
> The problem is that his post is quite contradictory. On the one hand he
> states that "Go is not and never has been a poll-driven language", yet
> at the same time, "I think it's reasonable to say that there is real
> support for adding generics" - because of the result of surveys!

I see no contradiction there.

These two statements can both be true: 1) the future of the Go
language is not determined by surveys; 2) we use surveys to find out
what Go users think.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXeZ9fm_4PgcxAqyDXTWa2wao_HG6RG%3D7TaqvDtEFdYEA%40mail.gmail.com.

Re: [go-nuts] Re: Generics, please go away!

[Ian Lance Taylor]

On Tue, Dec 22, 2020 at 1:46 PM Martin Hanson
 wrote:
>
> > I don't know of a poll specifically about generics. But for the past
> > several years we've done a Go community survey, and every year there
> > is significant support for adding generics to the language.
>
> So Ian, what you're saying is that for the future we can expect that
> future development of Go will be driven by surveys? And each time there
> is a significant support for adding or removing something, it will be
> done?

No, that is not what I am saying.

I was replying to Markus Heukelom comments about a poll and about
whether the community was asked whether they (the community) wanted
generics.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXB6oDjTR6g%3D0JrX0D80OmFwfDj2_0NZx4av_LWG%3DqJ6w%40mail.gmail.com.

Re: [go-nuts] Re: Generics, please go away!

['Axel Wagner' via golang-nuts]

On Tue, Dec 22, 2020 at 11:09 PM Martin Hanson 
wrote:

> If you on the other hand is pro-generics to Go, then of course that is
> your right.
>

Ian is on record, multiple times, as having argued in favor of generics in
Go long before its open source release and has since written many proposals
to add them - even before the Go community survey was a thing.

Again, it bears repeating: "The Go designers where against generics" is
historical fiction. "The Go team is succumbing to public pressure" is
political fiction. Both are simply false. Anyone saying either of those
either misunderstood something someone on the Go team said, or is repeating
from someone else who misunderstood something.

There are plenty of good reasons to criticize the addition of generics, but
neither of these is one.

I for one doesn't hope that the future of Go is going to continue down
> this road, with new proposals for change popping up on GitHub every
> other day and surveys and possible outside pressure determining the
> future of Go. I would very much like to know if this is going to be the
> way it is.


> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/6452721608674913%40iva4-57c3b416b70c.qloud-c.yandex.net
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfETh%3DDPf%2BkGR%2BW8b-w0C_bH_kePMYZNUTsJGtSShhKZoA%40mail.gmail.com.

Re: [go-nuts] Re: Generics, please go away!

[Artur Vianna]

Ultimately Go is a community and polls are unavoidable. And even in the
benevolent-dictator model, the dictator is forced by the community if the
pressure is high enough, this has happened in a lot of projects like Vim
and Python. And in Vim some changes only happened after the adoption of the
NeoVim fork created community pressure.

The community will be the force driving the project whether you want it or
not, the difference is that the Go team is actively seeking feedback,
instead of letting the things get out of control, and only then patching it
up.

Em ter., 22 de dez. de 2020 às 19:57, Martin Hanson <
greencopperm...@yandex.com> escreveu:

> > He did explicitly said in the last paragraph that Go is not driven by
> > pools (aka surveys).
>
> Please re-read!
>
> The problem is that his post is quite contradictory. On the one hand he
> states that "Go is not and never has been a poll-driven language", yet
> at the same time, "I think it's reasonable to say that there is real
> support for adding generics" - because of the result of surveys!
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/7296511608674192%40sas8-b090c2642e35.qloud-c.yandex.net
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAE%3DAWBV_cu2X2nYJ_367zSVjBQ9R7ikuuuzzVQ6%3DPUeOi%2BiEcw%40mail.gmail.com.

Re: [go-nuts] Re: Generics, please go away!

[Artur Vianna]

He did explicitly said in the last paragraph that Go is not driven by pools
(aka surveys).

On Tue, 22 Dec 2020, 18:46 Martin Hanson, 
wrote:

> > I don't know of a poll specifically about generics. But for the past
> > several years we've done a Go community survey, and every year there
> > is significant support for adding generics to the language.
>
> So Ian, what you're saying is that for the future we can expect that
> future development of Go will be driven by surveys? And each time there
> is a significant support for adding or removing something, it will be
> done?
>
> If the future of Go is going to be dictated by surveys and as such what
> the majority wants, then clearly Go needs to fork because a lot of us
> will NEVER want that to happen. We're VERY happy with Go, just the way
> it is.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/6385151608673540%40iva1-b50b8ed859e3.qloud-c.yandex.net
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAE%3DAWBUQ5Uxq4dyMYrXqL%2Bv-gBP2p23nuDydUa2Z5akeBAiNQQ%40mail.gmail.com.

Re: [go-nuts] Re: Generics, please go away!

[Ian Lance Taylor]

On Tue, Dec 22, 2020 at 1:24 AM Markus Heukelom
 wrote:
>
> Why not issue a poll on generics, was this ever done? (I could've missed it, 
> I  am only following Go ~2 years). While the community has a vote in 
> accepting/rejecting the current generics proposal, the community was never 
> (really) asked if generics is desired in the first place and especially what 
> the scope of generics should be. Is that correct?

I don't know of a poll specifically about generics.  But for the past
several years we've done a Go community survey, and every year there
is significant support for adding generics to the language.  For
example, although the results of the 2020 survey haven't been
assembled yet, you can see the results of the 2019 survey at
https://blog.golang.org/survey2019-results.  In that survey when asked
"Which critical language features do you need that are not available
in Go?", 25% of the survey takers answered the question, and of those
79% mentioned generics.  Previous years also showed support for adding
generics.  Of course this isn't definitive, since there was no clear
way for people they say that do not want generics.  But it's also not
definitive in a different direction, which is that by and large people
who don't currently use Go didn't take the survey, and probably some
of them would also want generics.

So while Go is not and never has been a poll-driven language, I think
it's reasonable to say that there is real support for adding generics.


> Another thought:  there are many popular, type-safe programming language with 
> generics already. So if you really need generics, there's plenty to pick 
> from. There's not that many  without, I can only name Go and C. So if 
> generics is added to Go there's far less choice to pick a modern type-safe 
> language that doesn't have generics. It's a feature that makes Go quite 
> special.

Actually, C does have generics, through the preprocessor macro
mechanism.  It's difficult to write, but it does provide the same kind
of functionality that would be available in Go if we added generics.
For example, here is a compile-time-type-safe vector implementation in
C:

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/vec.h;h=cb871124ce2241402af05e4697a5e28904c462fb;hb=HEAD
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/vec.c;h=85274c4e00c202e680761cef516bd17bb58b6261;hb=HEAD

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcU_rVJLP%3DG%3DdzMnvoD9HrJGBQcQ_Joc6oni2ggQxfxuqw%40mail.gmail.com.

Re: [go-nuts] Re: Generics, please go away!

[Space A.]

  > I have, plenty of times in the past, said myself that people who want 
generics should just use Java or C++. I'm not proud of saying that. It was 
a mistake. 

What if you actually were right? Have you ever been looking at it through 
"Clear is better than clever" prism? What if in 10 years you say: "Holy 
sh*t..." =) Sorry this might be my thought not yours.

I mean, what if lack of generics is actually one of the greatest feature of 
Go and we by all means should keep it like this. The fact is Go is great 
and successful without it, so do we really need to add anything? Because 
one of the key strengths is readability and clearness which you won't see 
anymore. And here you are, yet another boring language (I actually liked 
"write-only" term from one of comments above) which lacks so many features 
that others "had for years". Some ppl say "give it a chance", but giving 
something a chance means you can accept or deny if you don't like it. It's 
not a case because there is no magic switch you can turn on and off. There 
will be no way to reverse it.



вторник, 22 декабря 2020 г. в 16:07:20 UTC+3, axel.wa...@googlemail.com: 

> You are very welcome to voice your opinion. Including the opinion that 
> generics should not be added to Go.
> What you shouldn't do - and that's all I criticized - is to tell people 
> who disagree with you on that to go away.
>
> I also think it's not wrong to point out that claiming the original 
> designers of Go left out generics on purpose is, at least, distorting the 
> documented historical facts. Or to point out the contradiction in saying, 
> on the on hand, that we should listen to the original designers about what 
> does and does not belong into the design of Go and, on the other hand, 
> telling one of those exact designers that they are ruining the language.
>
> I'm genuinely sorry if you feel you can't voice your opinion based on my 
> message. But as best as I can tell, that is a reaction to a) me pointing 
> out exclusionary language or b) me pointing out logical problems with the 
> arguments presented.
> And if it's a) I must insist that the paradox of tolerance 
>  informs my decision 
> here - if I can only choose between people feeling excluded for wanting 
> generics or people feeling excluded because they can't make those people 
> feel excluded, I will have to choose the latter. And if it's b) I must 
> wonder why that isn't exactly the kind of technical, logical argument y'all 
> are looking for.
>
> To be clear, again, I have plenty of problems with generics in general and 
> with the current stage of the design in particular. For example, I am on 
> record as disagreeing with making usage of operators on type-arguments a 
> central part of the design - I feel that it creates most of the 
> complication in the design and I don't feel the benefit outweigh the cost. 
> But I understand and respect Ian's choice on that. It's a technical point 
> of contention and I politely disagree with him and live with that.
>
> I've also said, plenty of times, that I think the main use-case for 
> generics seem to be type-safe containers and that I feel the benefit of 
> type-safety there is overstated. And experimenting 
>  with the 
> current design for a while reinforced my impressions that some design 
> decisions (like not allowing additional type-parameters on methods) hamper 
> at least *some* of the non-container use-cases where Go could benefit from 
> more type-safety. However, again, I understand why those decisions where 
> made and I don't know of a way to solve these issues, so I'm left with 
> accepting that they might be the best possible solution, even if I don't 
> like them.
>
> As it currently stands, I'm undecided if I like generics in Go and 
> probably lean slightly against, given the current design (and would 
> probably lean in favor, with some changes). The decision is not up to me 
> though and I'm fine disagreeing with whatever decision is made - if it 
> comes to that. And living with it.
>
> I can't imagine any of these opinions about generics to earn me scorn or 
> reprimands based on the CoC. Because the issue isn't *disagreeing* with 
> generics or with voicing that opinion. It's *how* you voice it that matters 
> and if you do so in a respectful and technical manner.
>
> PS: Just make clear that I'm not claiming I'm perfect: I have, plenty of 
> times in the past, said myself that people who want generics should just 
> use Java or C++. I'm not proud of saying that. It was a mistake. I've done 
> plenty of those and I will make plenty of them in the future and I can just 
> hope I learn from them.
>
>

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

Re: [go-nuts] Re: Generics, please go away!

[burak serdar]

On Tue, Dec 22, 2020 at 12:09 PM Anthony Martin  wrote:
>
> 'Axel Wagner' via golang-nuts  once said:
> > What isn't welcome is your attempt of alienating people with a different
> > viewpoint from yours and make them feel unwelcome. And if you continue to
> > insist on doing that, the community *will* ask you to leave.
>
> Please don't minimize or silence the lived experience
> of people disproportionately affected by generics.
>
> We should protect non-generic function bodies.

I also developed some horrendous code using generics in Java. I can
relate to the resistance many are having against generics. However,
there are some differences in the Go generics implementation that
makes me hopeful, so I suggest those who are opposed to it to give it
a chance and try it. This is not Java generics that were forced into
the language without changing the underlying JVM. Nor is it C++ (yet)
that you can't really do anything useful without writing lots of
cryptic code just to keep the libraries happy. A balanced approach in
the library that doesn't impose generics on developers at every
possible opportunity may go a long way.

>
> Concrete code matters.
>
>   Anthony
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/X%2BJD0mE0ZzY7AyM2%40alice.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMV2Rqo1KgAp2F4BQRSsm9Zx4kviUEW4GRx6KnktBzmWp0LQRg%40mail.gmail.com.

Re: [go-nuts] Re: Generics, please go away!

['Carla Pfaff' via golang-nuts]

On Tuesday, 22 December 2020 at 20:09:42 UTC+1 al...@pbrane.org wrote:

> Please don't minimize or silence the lived experience 
> of people disproportionately affected by generics. 
>
> We should protect non-generic function bodies. 
>
> Concrete code matters. 
>

Tasteless attempt at humour.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20893718-5fd6-4ab9-b2bb-5742ef042d3cn%40googlegroups.com.

Re: [go-nuts] Re: Generics, please go away!

[Anthony Martin]

'Axel Wagner' via golang-nuts  once said:
> What isn't welcome is your attempt of alienating people with a different
> viewpoint from yours and make them feel unwelcome. And if you continue to
> insist on doing that, the community *will* ask you to leave.

Please don't minimize or silence the lived experience
of people disproportionately affected by generics.

We should protect non-generic function bodies.

Concrete code matters.

  Anthony

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/X%2BJD0mE0ZzY7AyM2%40alice.

Re: [go-nuts] Re: Generics, please go away!

['Axel Wagner' via golang-nuts]

You are very welcome to voice your opinion. Including the opinion that
generics should not be added to Go.
What you shouldn't do - and that's all I criticized - is to tell people who
disagree with you on that to go away.

I also think it's not wrong to point out that claiming the original
designers of Go left out generics on purpose is, at least, distorting the
documented historical facts. Or to point out the contradiction in saying,
on the on hand, that we should listen to the original designers about what
does and does not belong into the design of Go and, on the other hand,
telling one of those exact designers that they are ruining the language.

I'm genuinely sorry if you feel you can't voice your opinion based on my
message. But as best as I can tell, that is a reaction to a) me pointing
out exclusionary language or b) me pointing out logical problems with the
arguments presented.
And if it's a) I must insist that the paradox of tolerance
 informs my decision
here - if I can only choose between people feeling excluded for wanting
generics or people feeling excluded because they can't make those people
feel excluded, I will have to choose the latter. And if it's b) I must
wonder why that isn't exactly the kind of technical, logical argument y'all
are looking for.

To be clear, again, I have plenty of problems with generics in general and
with the current stage of the design in particular. For example, I am on
record as disagreeing with making usage of operators on type-arguments a
central part of the design - I feel that it creates most of the
complication in the design and I don't feel the benefit outweigh the cost.
But I understand and respect Ian's choice on that. It's a technical point
of contention and I politely disagree with him and live with that.

I've also said, plenty of times, that I think the main use-case for
generics seem to be type-safe containers and that I feel the benefit of
type-safety there is overstated. And experimenting
 with the
current design for a while reinforced my impressions that some design
decisions (like not allowing additional type-parameters on methods) hamper
at least *some* of the non-container use-cases where Go could benefit from
more type-safety. However, again, I understand why those decisions where
made and I don't know of a way to solve these issues, so I'm left with
accepting that they might be the best possible solution, even if I don't
like them.

As it currently stands, I'm undecided if I like generics in Go and probably
lean slightly against, given the current design (and would probably lean in
favor, with some changes). The decision is not up to me though and I'm fine
disagreeing with whatever decision is made - if it comes to that. And
living with it.

I can't imagine any of these opinions about generics to earn me scorn or
reprimands based on the CoC. Because the issue isn't *disagreeing* with
generics or with voicing that opinion. It's *how* you voice it that matters
and if you do so in a respectful and technical manner.

PS: Just make clear that I'm not claiming I'm perfect: I have, plenty of
times in the past, said myself that people who want generics should just
use Java or C++. I'm not proud of saying that. It was a mistake. I've done
plenty of those and I will make plenty of them in the future and I can just
hope I learn from them.

On Tue, Dec 22, 2020 at 1:22 PM Space A.  wrote:

> Your message is perfect example of why most of the ppl who have their own
> different opinion and who have never been listened to or given that ability
> will just shut up, and stay away.
>
> вторник, 22 декабря 2020 г. в 14:01:53 UTC+3, axel.wa...@googlemail.com:
>
>> On Tue, Dec 22, 2020 at 11:09 AM Martin Hanson 
>> wrote:
>>
>>> It's a matter of understanding why generics was left out of Go from the
>>> start, like classes was left out of Go. If we start adding stuff that
>>> the original developers of Go left out by purpose
>>
>>
>> That is some serious revisionism of the facts. Ian (who is spear-heading
>> the generics effort) is one of (if not *the*) first person to join Go's
>> development. And it has *always* been the communicated stance of the Go
>> team (including the original three people who've been there before him)
>> that generics would be nice to have, if they can figure out a way to fit
>> them in.
>>
>> I'm as skeptical about generics as the next guy. But this denial of
>> historical fact doesn't help anybody. Neither is exclusionary language like
>> talking about "true Gophers". Go is an inclusive project and wants everyone
>> to feel welcome - *obviously* that includes people who want generics in the
>> language. Please read - and keep to - the Go community Code of Conduct:
>> https://golang.org/conduct
>>
>>
>>
>>> we're not understanding the design choices that went into Go, which is
>>> exactly
>>> what makes Go unique!
>>>
>>
>> 

Re: [go-nuts] Re: Generics, please go away!

[Jan Mercl]

On Tue, Dec 22, 2020 at 1:02 PM Axel Wagner
 wrote:

> I feel well justified in calling this out as destructive behavior.

You've defined the problem much better than I could ever do. But this
one is not technical and off topic in this thread. Thanks for
considering.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-XJ1Tdw3%2BaEQ_H%3DFj-Rr0m2%3DUjRibc7CjHp%2Bk-wEGfnjQ%40mail.gmail.com.

Re: [go-nuts] Re: Generics, please go away!

[Space A.]

Your message is perfect example of why most of the ppl who have their own 
different opinion and who have never been listened to or given that ability 
will just shut up, and stay away.

вторник, 22 декабря 2020 г. в 14:01:53 UTC+3, axel.wa...@googlemail.com: 

> On Tue, Dec 22, 2020 at 11:09 AM Martin Hanson  
> wrote:
>
>> It's a matter of understanding why generics was left out of Go from the
>> start, like classes was left out of Go. If we start adding stuff that
>> the original developers of Go left out by purpose
>
>
> That is some serious revisionism of the facts. Ian (who is spear-heading 
> the generics effort) is one of (if not *the*) first person to join Go's 
> development. And it has *always* been the communicated stance of the Go 
> team (including the original three people who've been there before him) 
> that generics would be nice to have, if they can figure out a way to fit 
> them in.
>
> I'm as skeptical about generics as the next guy. But this denial of 
> historical fact doesn't help anybody. Neither is exclusionary language like 
> talking about "true Gophers". Go is an inclusive project and wants everyone 
> to feel welcome - *obviously* that includes people who want generics in the 
> language. Please read - and keep to - the Go community Code of Conduct: 
> https://golang.org/conduct
>
>  
>
>> we're not understanding the design choices that went into Go, which is 
>> exactly
>> what makes Go unique!
>>
>
> Go is not a religion. Go is not something that was prophetized on stone 
> tablets and handed down from mysterious, otherworldly gods.
> It's a programming language and a software project. The people who came up 
> with it and designed it are alive and well and they explain their decisions 
> regularly and patiently. One of those people is Ian.
>
> I am comparatively late to the party with adopting Go, but even I feel 
> comfortable saying I understand the design choices that went into Go.
>  
>
>> If you want to add generics to Go, if you want to change how errors are
>> handled, if you want X, Y or Z feature that Java, C++, or some other
>> complex language has got, then go use that language! Why are you even
>> here!?
>>
>
> I said so above but it benefits from repitition: If you are someone who 
> wants the language to change, if you want generics, if you feel error 
> handling could be improved, "if you want X, Y or Z feature that Java, C++, 
> or some other complex language has got", you are welcome in our community. 
> Your viewpoint is valued. Your, Martin, viewpoint that generics *shouldn't* 
> be added to Go is valued as well.
>
> What isn't welcome is your attempt of alienating people with a different 
> viewpoint from yours and make them feel unwelcome. And if you continue to 
> insist on doing that, the community *will* ask you to leave.
>
> the people who designed Go, and we all know who they are
>
>
> No offense, but I do get the impression that you actually don't.
>  
>
>> If generics gets added to Go, we're opening a very dangerous door, and
>> it will be the downfall of Go because - and Robert Griesemer this is
>> especially addressed to you - what's next then?
>
>
> Just to be clear: On the one hand, you are trying to make an argument that 
> the original designers of Go are impossible to understand, their competency 
> transcends reason and they should be trusted to come up with the best 
> design for a language. And on the other hand, you are trying to explain one 
> of those original designers, who is currently working on adding generics, 
> that what they are doing is "the downfall of Go"? Think about it. That 
> should really cause you some cognitive dissonance.
>  
>
>> If generics gets added to Go, we're a big enough part of the community,
>> that passionately hate that, that we can manage to fork Go - which I
>> strongly believe will then be the right thing to do!
>>
>
> I can say, I would genuinely be happy if a fork of Go without generics 
> will be made and if people who feel they can't live with a language 
> containing them migrate to that fork. Just as I was genuinely happy about 
> Devuan being created by people who feel they can't live with an operating 
> system using systemd. The Debian project became better by that fork 
> existing and I suspect, the Go project would be better with such a fork.
>
> Because it would give relentlessly negative people a place to be in peace, 
> somewhere else.
>  
>
>>
>> -- 
>> 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.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/5029411608631693%40iva7-919bb0034794.qloud-c.yandex.net
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving 

Re: [go-nuts] Re: Generics, please go away!

['Axel Wagner' via golang-nuts]

On Tue, Dec 22, 2020 at 12:46 PM Jan Mercl <0xj...@gmail.com> wrote:

> On Tue, Dec 22, 2020 at 12:01 PM 'Axel Wagner' via golang-nuts
>  wrote:
>
> > Go is an inclusive project and wants everyone to feel welcome -
> *obviously* that includes people who want generics in the language. Please
> read - and keep to - the Go community Code of Conduct:
> https://golang.org/conduct
>
> I have never read the CoC, but I don't expect it justifies implanting
> irrelevant social issues into a technical discussion like this to be
> used as an argument against a differing opinion. Please don't, thank
> you.
>

You might want to give it a read, then. It includes "Be friendly and
welcoming" as the first Gopher value. Saying "I think people who want
generics added to Go should go and program in Java or C++" and asking "Why
are you even here!?" is clearly the opposite of welcoming.

And, FTR, saying something is "a technical discussion" doesn't make it so.
This thread is almost exclusively about *social* issues - the arguments
brought forth are mostly talking about how decisions are made, baseless
claims that generics are added solely by majority decision or polls,
fear-mongering about slippery slopes, appeals to authority and trying to
create an us-vs-them and "threatening" to split the community. There is
very little technical content here.

I feel well justified in calling this out as destructive behavior.

Back to the topic. Yes, I agree that Go is going through a serious
> case of featuritis for some time. It's sad, but knowing there's
> nothing I can do about it, I'm not really frustrated. Afterall there
> are places where generics will be just fine. I will be frustrated,
> however, when I'll have to read generic code in places where it
> shouldn't be generic. Grep would no longer point me to a particular,
> plain readable implementation, which then would have to be built
> mentally only and that will be much more complicated to do.
>
> That will happen. It happens routinely in every other programming
> language that has generics. Because for so many it's so cool to write
> write-only code.
>
> I'm sometimes a sinner too.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGSn5vOjZ873WiemNSXOWKovbGM5dJJvG4ESTmdiFmNsA%40mail.gmail.com.

Re: [go-nuts] Re: Generics, please go away!

[Jan Mercl]

On Tue, Dec 22, 2020 at 12:01 PM 'Axel Wagner' via golang-nuts
 wrote:

> Go is an inclusive project and wants everyone to feel welcome - *obviously* 
> that includes people who want generics in the language. Please read - and 
> keep to - the Go community Code of Conduct: https://golang.org/conduct

I have never read the CoC, but I don't expect it justifies implanting
irrelevant social issues into a technical discussion like this to be
used as an argument against a differing opinion. Please don't, thank
you.

Back to the topic. Yes, I agree that Go is going through a serious
case of featuritis for some time. It's sad, but knowing there's
nothing I can do about it, I'm not really frustrated. Afterall there
are places where generics will be just fine. I will be frustrated,
however, when I'll have to read generic code in places where it
shouldn't be generic. Grep would no longer point me to a particular,
plain readable implementation, which then would have to be built
mentally only and that will be much more complicated to do.

That will happen. It happens routinely in every other programming
language that has generics. Because for so many it's so cool to write
write-only code.

I'm sometimes a sinner too.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-UgobmA9VjVGjLNQYnrq33ujyww8dp4QC5AKhfp2urL_w%40mail.gmail.com.

Re: [go-nuts] Re: Generics, please go away!

['Axel Wagner' via golang-nuts]

On Tue, Dec 22, 2020 at 11:09 AM Martin Hanson 
wrote:

> It's a matter of understanding why generics was left out of Go from the
> start, like classes was left out of Go. If we start adding stuff that
> the original developers of Go left out by purpose


That is some serious revisionism of the facts. Ian (who is spear-heading
the generics effort) is one of (if not *the*) first person to join Go's
development. And it has *always* been the communicated stance of the Go
team (including the original three people who've been there before him)
that generics would be nice to have, if they can figure out a way to fit
them in.

I'm as skeptical about generics as the next guy. But this denial of
historical fact doesn't help anybody. Neither is exclusionary language like
talking about "true Gophers". Go is an inclusive project and wants everyone
to feel welcome - *obviously* that includes people who want generics in the
language. Please read - and keep to - the Go community Code of Conduct:
https://golang.org/conduct



> we're not understanding the design choices that went into Go, which is
> exactly
> what makes Go unique!
>

Go is not a religion. Go is not something that was prophetized on stone
tablets and handed down from mysterious, otherworldly gods.
It's a programming language and a software project. The people who came up
with it and designed it are alive and well and they explain their decisions
regularly and patiently. One of those people is Ian.

I am comparatively late to the party with adopting Go, but even I feel
comfortable saying I understand the design choices that went into Go.


> If you want to add generics to Go, if you want to change how errors are
> handled, if you want X, Y or Z feature that Java, C++, or some other
> complex language has got, then go use that language! Why are you even
> here!?
>

I said so above but it benefits from repitition: If you are someone who
wants the language to change, if you want generics, if you feel error
handling could be improved, "if you want X, Y or Z feature that Java, C++,
or some other complex language has got", you are welcome in our community.
Your viewpoint is valued. Your, Martin, viewpoint that generics *shouldn't*
be added to Go is valued as well.

What isn't welcome is your attempt of alienating people with a different
viewpoint from yours and make them feel unwelcome. And if you continue to
insist on doing that, the community *will* ask you to leave.

the people who designed Go, and we all know who they are


No offense, but I do get the impression that you actually don't.


> If generics gets added to Go, we're opening a very dangerous door, and
> it will be the downfall of Go because - and Robert Griesemer this is
> especially addressed to you - what's next then?


Just to be clear: On the one hand, you are trying to make an argument that
the original designers of Go are impossible to understand, their competency
transcends reason and they should be trusted to come up with the best
design for a language. And on the other hand, you are trying to explain one
of those original designers, who is currently working on adding generics,
that what they are doing is "the downfall of Go"? Think about it. That
should really cause you some cognitive dissonance.


> If generics gets added to Go, we're a big enough part of the community,
> that passionately hate that, that we can manage to fork Go - which I
> strongly believe will then be the right thing to do!
>

I can say, I would genuinely be happy if a fork of Go without generics will
be made and if people who feel they can't live with a language containing
them migrate to that fork. Just as I was genuinely happy about Devuan being
created by people who feel they can't live with an operating system using
systemd. The Debian project became better by that fork existing and I
suspect, the Go project would be better with such a fork.

Because it would give relentlessly negative people a place to be in peace,
somewhere else.


>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/5029411608631693%40iva7-919bb0034794.qloud-c.yandex.net
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfE9nH1SaGUUrTUZwVR4ivYOcn3-5xGhS7WH3L1VRd7ENQ%40mail.gmail.com.

Re: [go-nuts] Re: Generics, please go away!

[Robert Engels]

A fork is a bad choice. Better to just not use them and/or prohibit them by 
policy in your org. A fork will die a slow painful death - this is a personal 
opinion only. 

> On Dec 21, 2020, at 11:50 AM, L Godioleskky  wrote:
> 
> Hopefully, the Go team will encapsulate all generics in a separate 
> module(s), so that those of us who want to ignore them can easily do so 
> 
>> On Monday, December 21, 2020 at 7:26:02 AM UTC-5 Space A. wrote:
>> Unfortunately it was expected that creators of the language will not resist 
>> forever being under the pressure of masses most which do not even code in 
>> Go, or not use Go as the main language and just following patterns and 
>> shitty idioms they took elsewhere. Generics are bullshit crap in its 
>> essence. They either don't improve anything or overused (with some huge 
>> cost). I'm telling this as someone who had 15+ years in Java before moved to 
>> Go. I was literally happy when I found that Go has almost everything which 
>> is good about programming and almost nothing bad. And I knew that it will 
>> start degrading at some point. I just keep some hopes that community will 
>> fork the language after this "Cyberpunk" releases. Rephrasing "no is 
>> temporary, yes is forever": good Go is temporary.
>> 
>> 
>> 
>> 
>> воскресенье, 20 декабря 2020 г. в 22:38:54 UTC+3, Martin Hanson: 
>>> I think people who want generics added to Go should go and program in Java 
>>> or C++. 
>>> 
>>> Adding generics to Go will ruin the beautiful simplicity of the language 
>>> and I haven't found a single example in which adding generics to Go pays 
>>> off. 
>>> 
>>> Even with the examples of having two almost identical functions reverse 
>>> some list, one of ints and one of strings, seriously!? We already have tons 
>>> and tons of open source reusable code that covers all use cases which 
>>> people complain about. 
>>> 
>>> Go was designed without generics purposefully from the start and Go is fine 
>>> just the way it is. 
>>> 
>>> Adding generics means that we're opening the door to the beginning of 
>>> bloating Go with all the crap that Java, C++ and all the other complex 
>>> languages has gotten over the years, and Go was designed specifically 
>>> without that clutter. So we add generics, then what? Classes? 
>>> 
>>> Adding generics to Go ruins that beautiful simplicity that went into the 
>>> design and the added complexity just isn't worth it! The standard library 
>>> have managed just fine without generics and so have we! 
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/ad1b3da3-f270-47f9-8c08-ffc5ea6cb5efn%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9D337DC2-339E-491F-9B56-7A052E9E7BA2%40ix.netcom.com.

Re: [go-nuts] Re: Generics, please go away!

[Artur Vianna]

Although i am also against generics, as i didn't even know it existed
before i started to see people complaining that Go didn't have it, i don't
think it will be that bad. It probably won't be overused for the same
reason interface{} isn't overused, the cases where it really makes sense
and is idiomatic go are very few, and when used out of these cases, they
will be pointed out by other people as bad practice.

Additionally the drafts for generics don't want to break the language, and
as such you can keep writing your standard Go as it never existed.

On Mon, 21 Dec 2020, 09:26 Space A.,  wrote:

> Unfortunately it was expected that creators of the language will not
> resist forever being under the pressure of masses most which do not even
> code in Go, or not use Go as the main language and just following patterns
> and shitty idioms they took elsewhere. Generics are bullshit crap in its
> essence. They either don't improve anything or overused (with some huge
> cost). I'm telling this as someone who had 15+ years in Java before moved
> to Go. I was literally happy when I found that Go has almost everything
> which is good about programming and almost nothing bad. And I knew that it
> will start degrading at some point. I just keep some hopes that community
> will fork the language after this "Cyberpunk" releases. Rephrasing "no is
> temporary, yes is forever": good Go is temporary.
>
>
>
>
> воскресенье, 20 декабря 2020 г. в 22:38:54 UTC+3, Martin Hanson:
>
>> I think people who want generics added to Go should go and program in
>> Java or C++.
>>
>> Adding generics to Go will ruin the beautiful simplicity of the language
>> and I haven't found a single example in which adding generics to Go pays
>> off.
>>
>> Even with the examples of having two almost identical functions reverse
>> some list, one of ints and one of strings, seriously!? We already have tons
>> and tons of open source reusable code that covers all use cases which
>> people complain about.
>>
>> Go was designed without generics purposefully from the start and Go is
>> fine just the way it is.
>>
>> Adding generics means that we're opening the door to the beginning of
>> bloating Go with all the crap that Java, C++ and all the other complex
>> languages has gotten over the years, and Go was designed specifically
>> without that clutter. So we add generics, then what? Classes?
>>
>> Adding generics to Go ruins that beautiful simplicity that went into the
>> design and the added complexity just isn't worth it! The standard library
>> have managed just fine without generics and so have we!
>>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/99ee1c1d-202c-421b-b63f-138d62e49dfcn%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAE%3DAWBVX5k6_4b8Mgsu9_DdMw5M7Ei0NZgo2E%3DP%2Bwn0uepZvcg%40mail.gmail.com.

Re: [go-nuts] Re: Generics, please go away!

[Kevin Chadwick]

On 12/21/20 12:26 PM, Space A. wrote:
> Unfortunately it was expected that creators of the language will not resist
> forever being under the pressure of masses

Whilst I don't agree with the language of these mails.

I have worries and struggle to see much benefit also.

Mostly I feel the time could be better spent elsewhere, though I am sure that I
am missing much of the picture.

It is said that it will only be used sparingly and some stdlib functions can
then be written that will be simpler to use.

Yet in Dart I even see examples for riverpod/provider for non generic code
written using Generic syntax, for demo purposes!

The performance will also be reduced, so wouldn't there be pressure for the
stdlib to keep duplicated more performant code, in most cases?


I take comfort in the airings that unlike Dart where dynamics were the norm
originally. It will be explicitly made clear that Generics are intended to be
far from a first resort.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b2fcd8b0-df4b-36cd-eba8-2ba2da110008%40gmail.com.