Generics, please go away!

2,404 views
Skip to first unread message

Martin Hanson

unread,
Dec 20, 2020, 2:38:54 PM12/20/20
to golan...@googlegroups.com
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!

Space A.

unread,
Dec 21, 2020, 7:26:02 AM12/21/20
to golang-nuts
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:

Kevin Chadwick

unread,
Dec 21, 2020, 10:40:41 AM12/21/20
to golang-nuts
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.

Md. Alim Ul Karim

unread,
Dec 21, 2020, 11:49:13 AM12/21/20
to golang-nuts
Not sure I agree with you.

Let's see others' thoughts on it.

Artur Vianna

unread,
Dec 21, 2020, 11:49:39 AM12/21/20
to Space A., golang-nuts
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.

--
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/99ee1c1d-202c-421b-b63f-138d62e49dfcn%40googlegroups.com.

Martin Hanson

unread,
Dec 21, 2020, 11:49:42 AM12/21/20
to golan...@googlegroups.com
I have just suggested the same thing @Space A, before I read your message and I agree fully!

https://github.com/golang/go/issues/15292#issuecomment-749032046

I strongly believe we need to fork Go if generics gets added and then let the toy people have their new shiny things in Go while we rename Go into something else and stay with Go 1. Then we need to have the first and most important rule, that NOTHING new gets added to Go 1.

Go definitely needs a fork if generics gets added!

L Godioleskky

unread,
Dec 21, 2020, 12:50:17 PM12/21/20
to golang-nuts
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 

Robert Engels

unread,
Dec 21, 2020, 12:57:26 PM12/21/20
to L Godioleskky, golang-nuts
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 <lgo...@gmail.com> 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 
--
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.

Markus Heukelom

unread,
Dec 22, 2020, 4:23:33 AM12/22/20
to golang-nuts
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? 

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.

To me, the most worrisome thing about the current generics proposal is that there'll be a constant choice/preference fight between writing

func MyFunc(r io.Reader) error {}

- or - 

func MyFunc[T io.Reader](r T) error {}

I hope I am wrong, but I have the feeling the latter looks cooler to a lot of programmers out there. 


wilk

unread,
Dec 22, 2020, 4:34:38 AM12/22/20
to golan...@googlegroups.com
It could be easy to fork Go and just forbid generics but you'll loose
all the libs that will use generics. And it's in libs that generics is
most usefull (like interfaces) !

I'm not so afraid of generics.
When i see the last draft, we can even says that we already have a form
of generics at method level with concept of interface since beginning.
When we use io.Reader, it's generic, we don't wait for a type.
The way generic are added it's not really generics like in
other langages, it's type parameters with constraints like with
interface with method. It's not really a new concept in Go.

We already can abuse of empty interface{}. It'll be the same with type
parameters, we could abuse of type 'any' but most of the time we'll use
type parameters with constraints, like interface with method and it'll
keep strong.

Sorry for my bad english, if somebody understand and could rewrite what
i mean ?

--
wilk

Martin Hanson

unread,
Dec 22, 2020, 5:09:05 AM12/22/20
to golan...@googlegroups.com
No polls. It's not a matter of majority rule!

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, we're not
understanding the design choices that went into Go, which is exactly
what makes Go unique!

Go was a major slap in the face to all the hype that has polluted the
programming industry for the past 30-40 years, which is why Go got so
much hate in the beginning from all the hype loving people.

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

The design choices that went into Go was not made randomly, nor were
they made by just anyone. Please understand that the people who
designed Go, and we all know who they are, had/has tons of experience
and the pragmatic approach they took is what make Go stand out so
beautifully!

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?
Let the community decide by majority!? Is that how we design a
professional programming language now? By majority rule?! NO! The
majority is all about hype and shine.

Adding generics to Go will rip out the spine of the philosophy of Go
and I for one will not be a part of that. I have more than 30 years of
experience in the business and I fully understand why generics and
classes and all the other clutter was left out of Go.

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!

Axel Wagner

unread,
Dec 22, 2020, 6:01:53 AM12/22/20
to Martin Hanson, golang-nuts
On Tue, Dec 22, 2020 at 11:09 AM Martin Hanson <greenco...@yandex.com> 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.

Jan Mercl

unread,
Dec 22, 2020, 6:47:32 AM12/22/20
to Axel Wagner, Martin Hanson, golang-nuts
On Tue, Dec 22, 2020 at 12:01 PM 'Axel Wagner' via golang-nuts
<golan...@googlegroups.com> 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.

Axel Wagner

unread,
Dec 22, 2020, 7:03:11 AM12/22/20
to Jan Mercl, Martin Hanson, 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
<golan...@googlegroups.com> 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.

Space A.

unread,
Dec 22, 2020, 7:21:46 AM12/22/20
to golang-nuts
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:

Jan Mercl

unread,
Dec 22, 2020, 7:23:09 AM12/22/20
to Axel Wagner, Martin Hanson, golang-nuts
On Tue, Dec 22, 2020 at 1:02 PM Axel Wagner
<axel.wa...@googlemail.com> 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.

Axel Wagner

unread,
Dec 22, 2020, 8:07:20 AM12/22/20
to Space A., 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.

Anthony Martin

unread,
Dec 22, 2020, 2:09:42 PM12/22/20
to golang-nuts
'Axel Wagner' via golang-nuts <golan...@googlegroups.com> 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

Carla Pfaff

unread,
Dec 22, 2020, 2:35:23 PM12/22/20
to 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.

burak serdar

unread,
Dec 22, 2020, 2:49:59 PM12/22/20
to Anthony Martin, golang-nuts
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...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/X%2BJD0mE0ZzY7AyM2%40alice.

Space A.

unread,
Dec 22, 2020, 3:08:06 PM12/22/20
to golang-nuts
  > 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:

Ian Lance Taylor

unread,
Dec 22, 2020, 3:49:48 PM12/22/20
to Markus Heukelom, golang-nuts
On Tue, Dec 22, 2020 at 1:24 AM Markus Heukelom
<markus....@gain.pro> 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

Martin Hanson

unread,
Dec 22, 2020, 4:46:35 PM12/22/20
to golan...@googlegroups.com
> 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.

Artur Vianna

unread,
Dec 22, 2020, 4:51:36 PM12/22/20
to Martin Hanson, golang-nuts
He did explicitly said in the last paragraph that Go is not driven by pools (aka 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...@googlegroups.com.

Martin Hanson

unread,
Dec 22, 2020, 4:57:34 PM12/22/20
to golan...@googlegroups.com
> 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!

Artur Vianna

unread,
Dec 22, 2020, 5:07:02 PM12/22/20
to Martin Hanson, golang-nuts
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.

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

Martin Hanson

unread,
Dec 22, 2020, 5:09:25 PM12/22/20
to golan...@googlegroups.com
@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.

Martin Hanson

unread,
Dec 22, 2020, 5:13:27 PM12/22/20
to golan...@googlegroups.com
> 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.

That's fair enough, if that is how it is. Then surely forking Go is not
going to be a problem because a large enough part of the community is
very much against changing Go.

Axel Wagner

unread,
Dec 22, 2020, 5:40:37 PM12/22/20
to Martin Hanson, golang-nuts
On Tue, Dec 22, 2020 at 11:09 PM Martin Hanson <greenco...@yandex.com> 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.

Ian Lance Taylor

unread,
Dec 22, 2020, 5:55:02 PM12/22/20
to Martin Hanson, golang-nuts
On Tue, Dec 22, 2020 at 1:46 PM Martin Hanson
<greenco...@yandex.com> 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

Ian Lance Taylor

unread,
Dec 22, 2020, 5:57:36 PM12/22/20
to Martin Hanson, golang-nuts
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

Gerald Henriksen

unread,
Dec 22, 2020, 5:58:10 PM12/22/20
to golan...@googlegroups.com
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.

Ian Lance Taylor

unread,
Dec 22, 2020, 6:04:43 PM12/22/20
to Martin Hanson, golang-nuts
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

Space A.

unread,
Dec 22, 2020, 6:19:25 PM12/22/20
to golang-nuts
> 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:

Axel Wagner

unread,
Dec 22, 2020, 6:51:27 PM12/22/20
to Space A., golang-nuts
On Wed, Dec 23, 2020 at 12:19 AM Space A. <reexi...@gmail.com> 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 <greenco...@yandex.com> 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.

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

Wojciech S. Czarnecki

unread,
Dec 22, 2020, 6:57:47 PM12/22/20
to golan...@googlegroups.com

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

Jeremy French

unread,
Dec 22, 2020, 10:40:12 PM12/22/20
to golang-nuts
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.

Robert Engels

unread,
Dec 23, 2020, 1:00:44 AM12/23/20
to Jeremy French, golang-nuts
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 <ibi...@gmail.com> 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.
--
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.

Alex Besogonov

unread,
Dec 23, 2020, 3:06:48 AM12/23/20
to golang-nuts
On Sunday, December 20, 2020 at 11: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++.
<troll mode>Perhaps you should switch to Python if you don't want generics?</troll mode>
 
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.
Can you provide concrete examples of code that would become more complicated and/or slower with the addition of generics? I'm genuinely researching it.

From what I see, most of complexity in other generic systems comes from co/contra-variance support which Go lacks, or in case of C++ from overcomplicated pattern-matching.

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 is unnecessary verbose in many places (for example, it lacks a very-much-needed map_keys(m) function). Moreover, lack of generics doesn't allow us to create custom collections with type safety (e.g. sync.Map).

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?
Java itself is not particularly complex in practice (its generic implementation is Turing-complete, but in practice complex generics are not used), most of the complexity comes from over-engineered third-party libraries.
 
Classes?
We already have 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!
The standard library actually has two generic types: map and array, along with a bunch of magic functions (like copy and delete).

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!

Kevin Chadwick

unread,
Dec 23, 2020, 5:43:02 AM12/23/20
to golang-nuts
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!

Axel Wagner

unread,
Dec 23, 2020, 6:20:24 AM12/23/20
to Kevin Chadwick, golang-nuts
On Wed, Dec 23, 2020 at 11:42 AM Kevin Chadwick <m8il...@gmail.com> 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.

Markus Heukelom

unread,
Dec 23, 2020, 6:32:23 AM12/23/20
to Ian Lance Taylor, golang-nuts
On Tue, Dec 22, 2020 at 9:48 PM Ian Lance Taylor <ia...@golang.org> wrote:
On Tue, Dec 22, 2020 at 1:24 AM Markus Heukelom
<markus....@gain.pro> 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.

Space A.

unread,
Dec 23, 2020, 7:12:34 AM12/23/20
to golang-nuts
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:

Martin Hanson

unread,
Dec 23, 2020, 7:17:22 AM12/23/20
to golan...@googlegroups.com
@Alex Besogonov:

> Can you provide concrete examples of code that would become more
> complicated and/or slower with the addition of generics? I'm
> genuinely researching it.

I'm not the one wanting to change the language, it's the other way
around. You have to provide concrete examples of why Go needs generics,
so far I haven't seen a single real life problem!

I haven't seen a single example, including the examples that Ian talks
about at GopherCon 2019, that honestly validates adding generics to Go.
Even Ian admits that adding generics will make Go much more complex.

https://www.youtube.com/watch?v=WzgLqE-3IhY

@Ian, for more than 10 years we have managed nicely without generics.
The number of times in my 30 years career as a developer I have come
across a situation in which I needed a generic solution to some data
array etc., is very rare, not something that happens often, and in such
rare circumstance I can certainly live with a bit of copy and paste.

Furthermore, haven't we already ALL developed all the
reverse/sort/whatever Go functions we need for all the different data
types?

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.

Am I to believe that all the pro-generics people are struggling on a
daily basis with copy pasting code all over the place because of
sorting, reversing, etc. problems in Go?! Come on already!

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

Kevin Chadwick

unread,
Dec 23, 2020, 7:19:20 AM12/23/20
to golang-nuts
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.

K. Alex Mills

unread,
Dec 23, 2020, 7:38:38 AM12/23/20
to Martin Hanson, golang-nuts
On Wed, Dec 23, 2020, 6:17 AM Martin Hanson <greenco...@yandex.com> 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.

Axel Wagner

unread,
Dec 23, 2020, 8:14:38 AM12/23/20
to Martin Hanson, golang-nuts
On Wed, Dec 23, 2020 at 1:17 PM Martin Hanson <greenco...@yandex.com> 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...@googlegroups.com.

Robert Engels

unread,
Dec 23, 2020, 8:43:46 AM12/23/20
to Axel Wagner, Martin Hanson, golang-nuts
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:



wilk

unread,
Dec 23, 2020, 10:36:23 AM12/23/20
to golan...@googlegroups.com
On 22-12-2020, Ian Lance Taylor wrote:
> On Tue, Dec 22, 2020 at 1:24 AM Markus Heukelom
><markus....@gain.pro> 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.

79% of 25% is really not a lot...

Errors was also cited but we've seen that even smallest change as `try`
was rejected.

I was one of them who wanted to improve err != nil, but finally after
looking and testing all the proposals i rejected all...

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

The problem is not really to can use generics when we want. Of course
every body want generics when he need it.
The problem is how will be used/abused generics when it just add
complexity when it would not add now...

Since years i've only one time needed generics to convert a Python lib,
then finally found a better anwser...

However, i understand that sometimes it's really usefull.

How to make sure that it's not abused ?

--
wilk

wilk

unread,
Dec 23, 2020, 10:45:25 AM12/23/20
to golan...@googlegroups.com
On 23-12-2020, Jeremy French wrote:
> I'd like to second the notion that the argument "if you don't like them,=20
> 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=20
> some, and we'll all be forced to deal with it.

+1

It's really a killer feature of Go. I gave somes lessons, it's unique
that we can teach 100% of the language in few days.
With generics we'll need one day more !

--
wilk

Space A.

unread,
Dec 23, 2020, 10:48:13 AM12/23/20
to golang-nuts
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:

Space A.

unread,
Dec 23, 2020, 10:56:08 AM12/23/20
to golang-nuts
> 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:

wilk

unread,
Dec 23, 2020, 11:23:55 AM12/23/20
to golan...@googlegroups.com
On 22-12-2020, Ian Lance Taylor wrote:
> On Tue, Dec 22, 2020 at 2:09 PM Martin Hanson
><greenco...@yandex.com> 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).

Do you believe the last draft respect all the conditions you wrote or
does it still need improvements ?

It's difficult to measure "simplicity" when adding anything new...

--
wilk

robert engels

unread,
Dec 23, 2020, 1:21:41 PM12/23/20
to Space A., golang-nuts
I meant success, as in ‘developer acceptance/enthusiasm’, not necessarily commercial success.

Kaveh Shahbazian

unread,
Dec 23, 2020, 4:14:29 PM12/23/20
to golang-nuts
Axel provided good insights about the history and the big picture of generics. Since the beginning, not having generics was not a goal - or a promise.


"Perl's time has passed because it has stopped evolving in some sense and Perl 6 is never going to arrive really. So Perl, in some sense missed the boat permanently".

Go covers operational system programming and infrastructure programming as well as application programming. The requirements for these two sides might differ drastically. For example on the infrastructure programming side, raw performance might be a requirement itself, so the importance of the code to be descriptive and be aligned with a domain language drops.

On the other hand, while Go provides a perfect set of language constructs, to apply all sort of decomposition best practices (the classics like SOLID), having generics, makes it possible to push these boundaries further (like applying DRY - when it makes sense - and being more descriptive in cases that we need to apply generic transformations/policies).

wilk

unread,
Dec 24, 2020, 2:43:35 AM12/24/20
to golan...@googlegroups.com
On 23-12-2020, Kaveh Shahbazian wrote:
> ------=_Part_8328_927921797.1608758069173
> Content-Type: multipart/alternative;
> boundary="----=_Part_8329_1642814539.1608758069173"
>
> ------=_Part_8329_1642814539.1608758069173
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> Axel provided good insights about the history and the big picture of=20
> generics. Since the beginning, not having generics was not a goal - or a=20
> promise.=20

Simplicity is still a goal :)

>
> From Computer Science - Brian Kernighan on successful language design=20
><https://youtu.be/Sg4U4r_AgJU?t=3D3451>:
>
> "Perl's time has passed because it has stopped evolving in some sense and=
>=20
> Perl 6 is never going to arrive really. So Perl, in some sense missed the=
>=20
> boat permanently".
>
> Go covers operational system programming and infrastructure programming as=
>=20
> well as application programming. The requirements for these two sides might=
>=20
> differ drastically. For example on the infrastructure programming side, raw=
>=20
> performance might be a requirement itself, so the importance of the code to=
>=20
> be descriptive and be aligned with a domain language drops.=20
>
> On the other hand, while Go provides a perfect set of language constructs,=
>=20
> to apply all sort of decomposition best practices (the classics like=20
> SOLID), having generics, makes it possible to push these boundaries further=
>=20
> (like applying DRY - when it makes sense - and being more descriptive in=20
> cases that we need to apply generic transformations/policies).
>
> On Wednesday, December 23, 2020 at 7:21:41 PM UTC+1 ren...@ix.netcom.com=20
> wrote:
>
>> I meant success, as in =E2=80=98developer acceptance/enthusiasm=E2=80=99,=
> not necessarily=20
>> commercial success.
>>
>> On Dec 23, 2020, at 9:48 AM, Space A. <reexi...@gmail.com> wrote:
>>
>> Prime driver of Java's success were enterprises with huge amount of=20
>> investments (money) into ecosystem along with all JSRs developed by=20
>> companies and groups with J2EE becoming de-facto a standard for building=
>=20
>> enterprise applications. And all this was happening way before any generi=
> cs.
>>
>> =D1=81=D1=80=D0=B5=D0=B4=D0=B0, 23 =D0=B4=D0=B5=D0=BA=D0=B0=D0=B1=D1=80=
>=D1=8F 2020 =D0=B3. =D0=B2 16:43:46 UTC+3, ren...@ix.netcom.com:=20
>>
>>> To add some weight to the pro generic side - from someone who doesn=E2=
>=80=99t=20
>>> necessarily think Go needs them - generics and more specifically the =E2=
>=80=9CJava=20
>>> Collections=E2=80=9D package was a prime driver in Java=E2=80=99s succes=
> s. Moving highly=20
>>> tuned and verified implementations into the core library removed a huge=
>=20
>>> burden on developers - allowing them to focus more time on application=
>=20
>>> structure/function rather than nuts and bolts - while gaining greater=20
>>> =E2=80=9Creadability=E2=80=9D as these apps used common/well known apis =
> as a foundation.=20
>>>
>>> On Dec 23, 2020, at 7:14 AM, 'Axel Wagner' via golang-nuts <
>>> golan...@googlegroups.com> wrote:
>>>
>>> =EF=BB=BF
>>>
>>> On Wed, Dec 23, 2020 at 1:17 PM Martin Hanson <greenco...@yandex.com>=20
>>> 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 fo=
> r=20
>>> several decades without functions, coroutines or hashtables. We did mana=
> ge=20
>>> for decades without portable programming languages or multi-tasking=20
>>> operating systems. We managed for many decades without the internet or t=
> he=20
>>> world wide web.
>>>
>>> In hindsight, though, "we managed so long without them" doesn't appear=
>=20
>>> to be a very convincing argument to not have them today.
>>> =20
>>>
>>>> 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=
>=20
>>> examples, but that you haven't found them convincing you that the benefi=
> ts=20
>>> outweigh the costs. Which is a completely valid position to take.=20
>>> Obviously, lots of other people (at least some of which you, I think,=20
>>> respect professionally) see that differently. Which is also completely=
>=20
>>> valid. So, confronted with that reality, there are many productive ways =
> to=20
>>> react. Some examples are
>>>
>>> =E2=80=A2 Try to engage in the design process to keep the cost down (i.e=
> . suggest=20
>>> simplifications to the generics design)
>>> =E2=80=A2 Try to engage in the design process to increase the benefits (=
> i.e.=20
>>> suggest improvements that increase its power)
>>> =E2=80=A2 Accept that it's possible for reasonable people to look at the=
> same=20
>>> problem and proposed solution and agree on what the costs and what the=
>=20
>>> benefits are, but weigh them differently, just as a matter of personal=
>=20
>>> taste or opinion - and thus agree to disagree
>>> =E2=80=A2 Try to change the other persons mind about what the costs or b=
> enefits=20
>>> are and how much they weigh
>>>
>>> Now, that last one *can* be very productive. Especially early on in a=20
>>> discussion, we tend to overlook hidden costs or surprising benefits and=
>=20
>>> having them pointed out can be really helpful. Personally, though, I mus=
> t=20
>>> say that the generics discussion has been going on for 10 years (and eve=
> n=20
>>> more, if we don't limit ourselves to Go) and I don't - personally - beli=
> eve=20
>>> that there is much hidden cost or surprising benefit left to be discover=
> ed.=20
>>> And ISTM that swaying someone's mind on them will most likely take more=
>=20
>>> 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=
>=20
>>> the best language? In that case, I'd personally suggest to focus on=20
>>> improving the generics design. Or do you want to convince others that th=
> eir=20
>>> valuation of costs and benefits is inaccurate? In that case, I'd persona=
> lly=20
>>> suggest to try and find new costs or benefits - but keep in mind, that 1=
> 0=20
>>> years is a lot of time for a lot of them to already have been mentioned =
> a=20
>>> lot. Or do you just want to be heard as being in disagreement? That's al=
> so,=20
>>> of course, valid.
>>>
>>> What I understand from all of this is that people who are pro-generics a=
> re
>>>> 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=20
>>> 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*=
>=20
>>> in favor of generics. Because just like you are frustrated that generics=
>=20
>>> are just nice to have (i.e. you perceive their actual benefit as=20
>>> insignificant), people on the other side of the aisle might be *just as*=
>=20
>>> frustrated by you, because generics are just slightly more complex (i.e.=
>=20
>>> they perceive their actual costs as insignificant). Your frustration is=
>=20
>>> 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 whini=
> ng
>>>> and complaining about Go for the past ten+ years to add further stuff=
>=20
>>>> that
>>>> is "nice to have", or change things they keep complaining about, like h=
> ow
>>>> Go handles errors and what not.
>>>>
>>>> After generics gets added, it's going to be something else next time, a=
> nd
>>>> 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 G=
> o!
>>>>
>>>> --=20
>>>> You received this message because you are subscribed to the Google=20
>>>> Groups "golang-nuts" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send=
>=20
>>>> an email to golang-nuts...@googlegroups.com.
>>>> To view this discussion on the web visit=20
>>>> https://groups.google.com/d/msgid/golang-nuts/17246551608725779%40iva4-=
> 6593cae50902.qloud-c.yandex.net
>>>> .
>>>>
>>>
>>> --=20
>>> You received this message because you are subscribed to the Google Group=
> s=20
>>> "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send a=
> n=20
>>> email to golang-nuts...@googlegroups.com.
>>>
>>> To view this discussion on the web visit=20
>>> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFVeWZcnMtWQ3gZNeJ46=
> GUFr68yYZtVa1YNmpQtbV-8yA%40mail.gmail.com=20
>>> <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFVeWZcnMtWQ3gZNeJ4=
> 6GUFr68yYZtVa1YNmpQtbV-8yA%40mail.gmail.com?utm_medium=3Demail&utm_source=
>=3Dfooter>
>>> .
>>>
>>>
>> --=20
>> You received this message because you are subscribed to the Google Groups=
>=20
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an=
>=20
>> email to golang-nuts...@googlegroups.com.
>>
>> To view this discussion on the web visit=20
>> https://groups.google.com/d/msgid/golang-nuts/5bc14220-c09f-4920-a11c-7bc=
> 2d9d3896cn%40googlegroups.com=20
>> <https://groups.google.com/d/msgid/golang-nuts/5bc14220-c09f-4920-a11c-7b=
> c2d9d3896cn%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
>> .
>>
>>
>>
>
> --=20
> 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 e=
> mail to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/=
> golang-nuts/5c3114cd-fcf4-4c17-aa92-026a8bb092b8n%40googlegroups.com.
>
> ------=_Part_8329_1642814539.1608758069173
> Content-Type: text/html; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
><div>Axel provided good insights about the history and the big picture of g=
> enerics. Since the beginning, not having generics was not a goal - or a pro=
> mise. <br></div><div><br></div><div>From <a href=3D"https://youtu.be/Sg4U4r=
> _AgJU?t=3D3451">Computer Science - Brian Kernighan on successful language d=
> esign</a>:</div><div><br></div><div>"Perl's time has passed because it has =
> stopped evolving in some sense and Perl 6 is never going to arrive really. =
> So Perl, in some sense missed the boat permanently".</div><div><br></div><d=
> iv>Go covers operational system programming and infrastructure programming =
> as well as application programming. The requirements for these two sides mi=
> ght differ drastically. For example on the infrastructure programming side,=
> raw performance might be a requirement itself, so the importance of the co=
> de to be descriptive and be aligned with a domain language drops. <br></div=
>><div><br></div><div>On the other hand, while Go provides a perfect set of =
> language constructs, to apply all sort of decomposition best practices (the=
> classics like SOLID), having generics, makes it possible to push these bou=
> ndaries further (like applying DRY - when it makes sense - and being more d=
> escriptive in cases that we need to apply generic transformations/policies)=
> .<br></div><br><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_=
> attr">On Wednesday, December 23, 2020 at 7:21:41 PM UTC+1 ren...@ix.netcom.=
> com wrote:<br/></div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0=
> 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><d=
> iv style=3D"word-wrap:break-word;line-break:after-white-space">I meant succ=
> ess, as in =E2=80=98developer acceptance/enthusiasm=E2=80=99, not necessari=
> ly commercial success.<br><div><br><blockquote type=3D"cite"></blockquote><=
> /div></div><div style=3D"word-wrap:break-word;line-break:after-white-space"=
>><div><blockquote type=3D"cite"><div>On Dec 23, 2020, at 9:48 AM, Space A. =
> &lt;<a href data-email-masked rel=3D"nofollow">reexi...@gmail.com</a>&gt; w=
> rote:</div><br></blockquote></div></div><div style=3D"word-wrap:break-word;=
> line-break:after-white-space"><div><blockquote type=3D"cite"><div>Prime dri=
> ver of Java&#39;s success were enterprises with huge amount of investments =
> (money) into ecosystem along with all JSRs developed by companies and group=
> s with J2EE becoming de-facto a standard for building enterprise applicatio=
> ns. And all this was happening way before any generics.<br><br><div class=
>=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">=D1=81=D1=80=D0=B5=
>=D0=B4=D0=B0, 23 =D0=B4=D0=B5=D0=BA=D0=B0=D0=B1=D1=80=D1=8F 2020 =D0=B3. =
>=D0=B2 16:43:46 UTC+3, ren...@<a href=3D"http://ix.netcom.com" target=3D"_b=
> lank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?h=
> l=3Den&amp;q=3Dhttp://ix.netcom.com&amp;source=3Dgmail&amp;ust=3D1608839208=
> 891000&amp;usg=3DAFQjCNF9wKbLNhpsDp4PKWpu4gD51lnmfw">ix.netcom.com</a>: <br=
>></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 0.8ex;border=
> -left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><div d=
> ir=3D"ltr">To add some weight to the pro generic side - from someone who do=
> esn=E2=80=99t necessarily think Go needs them - generics and more specifica=
> lly the =E2=80=9CJava Collections=E2=80=9D package was a prime driver in Ja=
> va=E2=80=99s success. Moving highly tuned and verified implementations into=
> the core library removed a huge burden on developers - allowing them to fo=
> cus more time on application structure/function rather than nuts and bolts =
> - while gaining greater =E2=80=9Creadability=E2=80=9D as these apps used co=
> mmon/well known apis as a foundation.=C2=A0</div><div dir=3D"ltr"><br><bloc=
> kquote type=3D"cite">On Dec 23, 2020, at 7:14 AM, &#39;Axel Wagner&#39; via=
> golang-nuts &lt;<a rel=3D"nofollow">golan...@googlegroups.com</a>&gt; wrot=
> e:<br><br></blockquote></div><blockquote type=3D"cite"><div dir=3D"ltr">=EF=
>=BB=BF</div></blockquote></div><div dir=3D"auto"><blockquote type=3D"cite">=
><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">On Wed, Dec 23, 2020 at =
> 1:17 PM Martin Hanson &lt;<a rel=3D"nofollow">greenco...@yandex.com</a>&gt;=
> wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
> e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
> ;padding-left:1ex">@Ian, for more than 10 years we have managed nicely with=
> out generics.<br></blockquote><div><br></div><div>Of course, this doesn&#39=
> ;t answer how we&#39;d have managed *with* them.</div><div><br></div><div>W=
> e did manage for decades without general purpose CPUs. We did manage for se=
> veral decades without functions, coroutines or hashtables. We did manage fo=
> r decades without portable programming languages or multi-tasking operating=
> systems. We managed for many decades without the internet or the world wid=
> e web.</div><div><br></div><div>In hindsight, though,=C2=A0 &quot;we manage=
> d so long without them&quot; doesn&#39;t appear to be a very convincing arg=
> ument to not have them today.</div><div>=C2=A0</div><blockquote class=3D"gm=
> ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
> 204,204);padding-left:1ex">So what is the real true-life problems that vali=
> dates adding generics<br>
> to Go? I haven&#39;t seen a single example, seriously not one! I have only<=
> br>
> seen useless examples like the one Ian gives in the talk, which of<br>
> course I know only serves as an example, but we need real life problems<br>
> to solve, not theoretical ones.<br></blockquote><div><br></div><div>To me, =
> this suggests that the issue isn&#39;t that you haven&#39;t seen enough exa=
> mples, but that you haven&#39;t found them convincing you that the benefits=
> outweigh the costs. Which is a completely valid position to take. Obviousl=
> y, lots of other people (at least some of which you, I think, respect profe=
> ssionally) see that differently. Which is also completely valid. So, confro=
> nted with that reality, there are many productive ways to react. Some examp=
> les are</div><div><br></div><div>=E2=80=A2 Try to engage in the design proc=
> ess to keep the cost down (i.e. suggest simplifications to the generics des=
> ign)</div><div>=E2=80=A2 Try to engage in the design process to increase th=
> e benefits (i.e. suggest improvements that increase its power)</div><div>=
>=E2=80=A2 Accept that it&#39;s possible for reasonable people to look at th=
> e same problem and proposed solution and agree on what the costs and what t=
> he benefits are, but weigh them differently, just as a matter of personal t=
> aste or opinion - and thus agree to disagree</div><div>=E2=80=A2 Try to cha=
> nge the other persons mind about what the costs or benefits are and how muc=
> h they weigh</div><div><br></div><div>Now, that last one *can* be very prod=
> uctive. Especially early on in a discussion, we tend to overlook hidden cos=
> ts or surprising benefits and having them pointed out can be really helpful=
> . Personally, though, I must say that the generics discussion has been goin=
> g on for 10 years (and even more, if we don&#39;t limit ourselves to Go) an=
> d I don&#39;t - personally - believe that there is much hidden cost or surp=
> rising benefit left to be discovered. And ISTM that swaying someone&#39;s m=
> ind on them will most likely take more than just outright saying that you d=
> on&#39;t agree.</div><div><br></div><div>So, I guess the question really is=
> , what&#39;s the goal? Do you want to get the best language? In that case, =
> I&#39;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&#39;d personally suggest to try and find new co=
> sts or benefits - but keep in mind, that 10 years is a lot of time for a lo=
> t of them to already have been mentioned a lot. Or do you just want to be h=
> eard as being in disagreement? That&#39;s also, of course, valid.</div><div=
>><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
> 8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What I underst=
> and from all of this is that people who are pro-generics are<br>
> in reality really talking about something that is *nice to have*, not<br>
> something that is seriously needed and this is where I become really<br>
> frustrated!</blockquote><div><br></div><div>I understand this frustration. =
> But it might help to keep in mind that computers are simply nice to have in=
> exactly the same way.</div><div>And I think there&#39;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 t=
> heir actual benefit as insignificant), people on the other side of the aisl=
> e 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.</div><div><br></div><blockquote cl=
> ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
> rgb(204,204,204);padding-left:1ex"> As I have said many times now, adding =
> stuff to Go comes with<br>
> a heavy price, it opens the door for all the people who have been whining<b=
> r>
> and complaining about Go for the past ten+ years to add further stuff that<=
> br>
> is &quot;nice to have&quot;, or change things they keep complaining about, =
> like how<br>
> Go handles errors and what not.<br>
><br>
> After generics gets added, it&#39;s going to be something else next time, a=
> nd<br>
> again and again. The list goes on and on about changes people want to<br>
> make to Go. Not real life problems, just so-called &quot;nice to have&quot;=
> .<br>
><br>
> No, the added and increased complexity I have witness in other<br>
> programming languages over the past 3-4 decades, because of exactly<br>
> things like this, is absolutely mind blowing. This must not happen to Go!<b=
> r>
><br>
> -- <br>
> You received this message because you are subscribed to the Google Groups &=
> quot;golang-nuts&quot; group.<br>
> To unsubscribe from this group and stop receiving emails from it, send an e=
> mail to <a rel=3D"nofollow">golang-nuts...@googlegroups.com</a>.<br>
> To view this discussion on the web visit <a href=3D"https://groups.google.c=
> om/d/msgid/golang-nuts/17246551608725779%40iva4-6593cae50902.qloud-c.yandex=
> .net" rel=3D"noreferrer nofollow" target=3D"_blank" data-saferedirecturl=3D=
> "https://www.google.com/url?hl=3Den&amp;q=3Dhttps://groups.google.com/d/msg=
> id/golang-nuts/17246551608725779%2540iva4-6593cae50902.qloud-c.yandex.net&a=
> mp;source=3Dgmail&amp;ust=3D1608839208893000&amp;usg=3DAFQjCNEEejduiYzwLc2i=
> N-77_DjGoQGuDQ">https://groups.google.com/d/msgid/golang-nuts/1724655160872=
> 5779%40iva4-6593cae50902.qloud-c.yandex.net</a>.<br>
></blockquote></div></div><div><br></div>
>
> -- <br>
> You received this message because you are subscribed to the Google Groups &=
> quot;golang-nuts&quot; group.<br>
> To unsubscribe from this group and stop receiving emails from it, send an e=
> mail to <a rel=3D"nofollow">golang-nuts...@googlegroups.com</a>.<br></div><=
> /blockquote></div><div dir=3D"auto"><blockquote type=3D"cite"><div dir=3D"l=
> tr">
> To view this discussion on the web visit <a href=3D"https://groups.google.c=
> om/d/msgid/golang-nuts/CAEkBMfFVeWZcnMtWQ3gZNeJ46GUFr68yYZtVa1YNmpQtbV-8yA%=
> 40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollo=
> w" target=3D"_blank" data-saferedirecturl=3D"https://www.google.com/url?hl=
>=3Den&amp;q=3Dhttps://groups.google.com/d/msgid/golang-nuts/CAEkBMfFVeWZcnM=
> tWQ3gZNeJ46GUFr68yYZtVa1YNmpQtbV-8yA%2540mail.gmail.com?utm_medium%3Demail%=
> 26utm_source%3Dfooter&amp;source=3Dgmail&amp;ust=3D1608839208893000&amp;usg=
>=3DAFQjCNEHWrFyipsGjUtPIeUdMXuDk__IQg">https://groups.google.com/d/msgid/go=
> lang-nuts/CAEkBMfFVeWZcnMtWQ3gZNeJ46GUFr68yYZtVa1YNmpQtbV-8yA%40mail.gmail.=
> com</a>.<br>
></div></blockquote></div></blockquote></div><div><br></div>
>
> -- <br>
> You received this message because you are subscribed to the Google Groups &=
> quot;golang-nuts&quot; group.<br>
> To unsubscribe from this group and stop receiving emails from it, send an e=
> mail to <a href data-email-masked rel=3D"nofollow">golang-nuts...@googlegro=
> ups.com</a>.<br></div></blockquote></div></div><div style=3D"word-wrap:brea=
> k-word;line-break:after-white-space"><div><blockquote type=3D"cite"><div>
> To view this discussion on the web visit <a href=3D"https://groups.google.c=
> om/d/msgid/golang-nuts/5bc14220-c09f-4920-a11c-7bc2d9d3896cn%40googlegroups=
> .com?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" rel=3D"n=
> ofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=
>=3Dhttps://groups.google.com/d/msgid/golang-nuts/5bc14220-c09f-4920-a11c-7b=
> c2d9d3896cn%2540googlegroups.com?utm_medium%3Demail%26utm_source%3Dfooter&a=
> mp;source=3Dgmail&amp;ust=3D1608839208893000&amp;usg=3DAFQjCNEpd4w7Yc9wxOLA=
> xjTiEBCA5YveGg">https://groups.google.com/d/msgid/golang-nuts/5bc14220-c09f=
> -4920-a11c-7bc2d9d3896cn%40googlegroups.com</a>.<br>
></div></blockquote></div><br></div></blockquote></div>
>
><p></p>
>
> -- <br />
> You received this message because you are subscribed to the Google Groups &=
> quot;golang-nuts&quot; group.<br />
> To unsubscribe from this group and stop receiving emails from it, send an e=
> mail to <a href=3D"mailto:golang-nuts...@googlegroups.com">golang-=
> nuts+uns...@googlegroups.com</a>.<br />
> To view this discussion on the web visit <a href=3D"https://groups.google.c=
> om/d/msgid/golang-nuts/5c3114cd-fcf4-4c17-aa92-026a8bb092b8n%40googlegroups=
> .com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/ms=
> gid/golang-nuts/5c3114cd-fcf4-4c17-aa92-026a8bb092b8n%40googlegroups.com</a=
>>.<br />
>
> ------=_Part_8329_1642814539.1608758069173--
>
> ------=_Part_8328_927921797.1608758069173--
>


--
wilk

Kaveh Shahbazian

unread,
Dec 24, 2020, 10:10:21 AM12/24/20
to golang-nuts
Simplicity is not an easy topic to discuss. Personally, I would like to define simplicity in the source code in terms of complexity. In the code, complexity comes from the irreversibility of our design decisions.

Go has no need for generics on the receiver side. It is possible to define ad-hoc higher-order kinds using interfaces. The problem arises on the calling side - calling a function/method - when the types of the arguments are not known at the time/place the container type is being defined.

One good example of this would be in the scenarios that a callback function/method should be called - with a specific type that is not known at this point.

This part of Rob Pike's interview is very interesting to me: "I am not a fan of type-driven programming, type hierarchies and classes and inheritance. Although many hugely successful projects have been built that way, I feel the approach pushes important decisions too early into the design phase, before experience can influence it. In other words, I prefer composition to inheritance".

There are many different levels of awareness about good design in this single piece. I love the part "I feel the approach pushes important decisions too early into the design phase, before experience can influence it" because it emphasizes the importance of letting design decisions to take shape based on the problem at hand - not the solution we think we have ready in our mind from past experiences. It shows the importance of keeping our design decisions reversible. The importance of writing disposable code - vs reusable code. Reusability IMHO is one of the most counterproductive notions in software development ever. In my mind "I prefer composition to inheritance" translates to "I prefer disposable code over reusable code". How much of the code that we write is supposed to be reusable anyway? (unless we are writing a library or a framework). And it a piece of code is easily disposable, it is reusable by design.

On the other hand, while writing some library that is meant to be reusable, falling back to empty interfaces is not exactly optimal. Go is no more the cool tool around the corner to be used by cool guys for their new shiny thing. Big companies are relying on Go to deliver their services - their existence. And in that space, generics become something of value.

Using generics (or more correctly parametric polymorphism as Rob Pike's put) have outcomes that go beyond just having more descriptive code. On-boarding and code-reviews, for example, will get easier/smoother.

It is said that "for every complex problem there is an answer that is clear, simple, and wrong". If the intention is to "simplify" the concept of the spacetime continuum, it is only possible to reduce the level of complexity of the concept to a level that still is inside the domain of Physics - unless we stop caring for that and like to enter the domain of "x for dummies" and "learn x in 24 hours", which is another story.

There is no entanglement between different levels of functionality - abstraction levels. There is no inheritance in Go. I love the fact that is it impossible to override a method that is being called by another method, without overriding the caller method too. Because that way, we only have to look at the same level to understand what is going on in that part. Also, it is not possible to "overload" anything - any function/method. Having these facts in mind, the way the proposal implements generics is all about clearer piping of functionality - not building towers of functionality.

Anthony Martin

unread,
Dec 25, 2020, 12:57:27 AM12/25/20
to Carla Pfaff, golang-nuts
> Tasteless attempt at humour.

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

Anthony

redsto...@gmail.com

unread,
Dec 25, 2020, 8:09:59 AM12/25/20
to golang-nuts
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?

Henrik Johansson

unread,
Dec 25, 2020, 11:49:26 AM12/25/20
to redsto...@gmail.com, golang-nuts
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?

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

Bakul Shah

unread,
Dec 25, 2020, 1:28:59 PM12/25/20
to golang-nuts
On Dec 25, 2020, at 8:48 AM, Henrik Johansson <dahan...@gmail.com> wrote:
>
> 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?

As Simon Peyton Jones has said, static types have been the most *successful* program verification technique! The more your types can express what you want your programs to do, the more the compiler can check them for you (and reject bad programs upfront). If types can be made more expressive (such as with generics) *without* making programs more incomprehensible (and less fun) it is a win!

As for the "simplicity" argument, he simplicity of user programs should be considered even more important than that of the language. That is, can you express your programs simply (without having to build in the kitchen sink in the language)?

Clearly there are things such as printing/parsing, serialization/deserialization, copying, collections, counting elements, more general processing of collections, graph algorithms etc. that can benefit from generics. Go has builtin support for a few specific generic functions. Things like len(), copy(), append(), range, new(), make() etc. But notice how range is rather strange. Proper generics support from the beginning might have produced a different kind of range. Ideally user defined types should be as first class as builtin types (including support for generics). Go falls short in this regard (IMHO).

Space A.

unread,
Dec 25, 2020, 2:28:54 PM12/25/20
to golang-nuts
What a ridiculous bullshit.

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

Wojciech S. Czarnecki

unread,
Dec 25, 2020, 3:03:44 PM12/25/20
to golan...@googlegroups.com
Dnia 2020-12-25, o godz. 11:28:54
"Space A." <reexi...@gmail.com> napisał(a):

> What a ridiculous bullshit.

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

redsto...@gmail.com

unread,
Dec 25, 2020, 9:32:54 PM12/25/20
to golang-nuts
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
<markus....@gain.pro> 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.


Christian Staffa

unread,
Dec 26, 2020, 4:32:31 AM12/26/20
to redsto...@gmail.com, golang-nuts
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 <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.
--
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.

wilk

unread,
Dec 26, 2020, 5:36:31 AM12/26/20
to golan...@googlegroups.com
On 26-12-2020, Christian Staffa wrote:
> I would rather have a survey with generics specific question that would she=
> d a better light to this topic. at least now, after following this discussi=
> on. i also think that it could be good to add it but is it worth when it al=
> so adds complexity? then i would say no thank you. go is powerful and simpl=
> e but after that it would be powerful and complex. i think it would be bett=
> er for go to solve the error handling. this would also make the go code bet=
> ter readable which would help the language more than adding generics if it =
> is a good solution, i think =F0=9F=92=AD=20

Maybe adding generics will help handling error ?

--
wilk

Jeremy French

unread,
Dec 26, 2020, 10:14:11 AM12/26/20
to Henrik Johansson, redsto...@gmail.com, golang-nuts
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.

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

Henrik Johansson

unread,
Dec 26, 2020, 11:39:42 AM12/26/20
to Jeremy French, redsto...@gmail.com, golang-nuts
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.

L Godioleskky

unread,
Dec 28, 2020, 12:35:40 PM12/28/20
to golang-nuts
" 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? ... "

.. AI, followed by cryto currency and asexual repoduction
On Tuesday, December 22, 2020 at 5:09:05 AM UTC-5 Martin Hanson wrote:
No polls. It's not a matter of majority rule!

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, we're not
understanding the design choices that went into Go, which is exactly
what makes Go unique!

Go was a major slap in the face to all the hype that has polluted the
programming industry for the past 30-40 years, which is why Go got so
much hate in the beginning from all the hype loving people.

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

The design choices that went into Go was not made randomly, nor were
they made by just anyone. Please understand that the people who
designed Go, and we all know who they are, had/has tons of experience
and the pragmatic approach they took is what make Go stand out so
beautifully!

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?
Let the community decide by majority!? Is that how we design a
professional programming language now? By majority rule?! NO! The
majority is all about hype and shine.

Adding generics to Go will rip out the spine of the philosophy of Go
and I for one will not be a part of that. I have more than 30 years of
experience in the business and I fully understand why generics and
classes and all the other clutter was left out of Go.

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!

Rick Timmis

unread,
Dec 29, 2020, 4:32:30 AM12/29/20
to golang-nuts
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.

L Godioleskky

unread,
Dec 29, 2020, 11:01:54 AM12/29/20
to golang-nuts
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)

Jan Mercl

unread,
Dec 29, 2020, 11:04:49 AM12/29/20
to L Godioleskky, golang-nuts
On Tue, Dec 29, 2020 at 5:01 PM L Godioleskky <lgo...@gmail.com> 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.

Alex Besogonov

unread,
Dec 29, 2020, 3:27:45 PM12/29/20
to golang-nuts
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).

redsto...@gmail.com

unread,
Dec 29, 2020, 11:07:03 PM12/29/20
to golang-nuts
Of course generics will make everything harder. We learn harder, we read harder, we think harder, we write harder. I use C++ for more than 10 years. I know the harder. Whether or not experience is improving, life is harder and the language is rotten.

Space A.

unread,
Dec 30, 2020, 7:27:15 AM12/30/20
to golang-nuts
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:

Vivi

unread,
Dec 30, 2020, 8:36:00 AM12/30/20
to golang-nuts
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.

Jeremy French

unread,
Dec 30, 2020, 2:16:35 PM12/30/20
to Vivi, golang-nuts
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.

--
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...@googlegroups.com.

Axel Wagner

unread,
Dec 30, 2020, 2:40:29 PM12/30/20
to Jeremy French, Vivi, golang-nuts
Hi,

On Wed, Dec 30, 2020 at 8:16 PM Jeremy French <jer...@frenches.com> 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

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.
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/CA%2Bj6mhDjqjXVMJ8q52cYDKfxrf9dUA90kuB%2BTg2G57KtCEiPWg%40mail.gmail.com.

nichol...@gmail.com

unread,
Dec 30, 2020, 2:46:12 PM12/30/20
to golang-nuts
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.

Space A.

unread,
Dec 30, 2020, 3:23:35 PM12/30/20
to golang-nuts
> 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.

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



среда, 30 декабря 2020 г. в 22:46:12 UTC+3, nichol...@gmail.com:

Alex Besogonov

unread,
Dec 31, 2020, 3:26:35 PM12/31/20
to golang-nuts
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?

Axel Wagner

unread,
Dec 31, 2020, 6:11:27 PM12/31/20
to Alex Besogonov, golang-nuts
On Thu, Dec 31, 2020 at 9:27 PM Alex Besogonov <alex.be...@gmail.com> 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...@googlegroups.com.

Space A.

unread,
Dec 31, 2020, 7:23:15 PM12/31/20
to Alex Besogonov, golang-nuts
> 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.






чт, 31 дек. 2020 г. в 23:27, Alex Besogonov <alex.be...@gmail.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...@googlegroups.com.

Space A.

unread,
Dec 31, 2020, 8:36:39 PM12/31/20
to Alex Besogonov, golang-nuts
Missed your second question.
 
> 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?

Can it? I use Go. I never said anywhere that there is some language like Python, that Go should take from. Instead I was always saying it must differentiate. I see no problem in using other languages if they do well for other people, so I don't understand why so many here want Go to become yet another Java. If you go by this way, Go will always be just a niche thing, "bad copy" which lacks so many cool features. And as I said in my reply to the very first message of the thread, I will go for the fork of Go1, if it happens. But unfortunately it seems that I will be forced to live with generics. There will be absolutely no way to use Go without them when it's landed.

Axel Wagner

unread,
Dec 31, 2020, 9:17:16 PM12/31/20
to Space A., Alex Besogonov, golang-nuts
On Fri, Jan 1, 2021 at 1:23 AM Space A. <reexi...@gmail.com> 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:

But either way, if you don't mind me asking: What exactly does any of this have to do with 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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CADKwOTd4%3DiPTtyBRhFW-aQFoEMd0jsVzrSUhTb2PtLyMWKxHiQ%40mail.gmail.com.

Alex Besogonov

unread,
Jan 1, 2021, 1:37:39 AM1/1/21
to Axel Wagner, golang-nuts

On Dec 31, 2020, at 15:10, Axel Wagner <axel.wa...@googlemail.com> wrote:

On Thu, Dec 31, 2020 at 9:27 PM Alex Besogonov <alex.be...@gmail.com> 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).
Yes, it does make it usable. See: https://play.golang.org/p/IqxpujkqXnO

There’s simply no automatic upcasting.

Axel Wagner

unread,
Jan 1, 2021, 5:22:02 AM1/1/21
to Alex Besogonov, golang-nuts
This is getting increasingly off-topic, but:

On Fri, Jan 1, 2021 at 7:37 AM Alex Besogonov <alex.be...@gmail.com> wrote:
Yes, it does make it usable. See: https://play.golang.org/p/IqxpujkqXnO

I don't understand the definition of subtyping you are using. AIUI, you would also argue that `Base` is a subtype of `int`, because you can write `&b.val` to get an `*int` and thus "use a `Base` as an `int`", correct? Because if so, I don't think that's a very common understanding of the word subtype.

There’s simply no automatic upcasting.

 The definition of subtyping I tend to rely on is "S is a subtype of T, if you can safely substitute a term of type T with a term of type S" (the Liskov substitution principle). That is, in the example, you would have to be able to replace `Base{}` (which is a term of type Base) with `Derived{}` (which is a term of type Derived). Clearly, that's not the case: https://play.golang.org/p/JnAMIUPNX82

It *is* the case (though that's not necessarily easy to see) if S is assignable to T - which among other things, is the case if T is an interface type and S implements T.

FWIW, after looking at this section of Wikipedia I can say I was wrong to equate the terms "inheritance" and "subtyping", though. The article about inheritance doesn't contain a definition I feel comfortable arguing about, so I don't want to really make an argument about Go having or not having inheritance. I would say, though, that this sentence seems to strongly imply that struct-embedding also does not constitute inheritance (and it reflects what I would call a commonly held opinion in the Go community):

Inheritance is contrasted with object composition, where one object contains another object (or objects of one class contain objects of another class); see composition over inheritance. Composition implements a has-a relationship, in contrast to the is-a relationship of subtyping.

(funnily enough, this sentence also implies that inheritance and subtyping are the same, even though the sentence before that calls out that they aren't. It's sometimes quite frustrating arguing about computer science, where apparently no one really agrees what the definitions are, that we argue about…)

Space A.

unread,
Jan 1, 2021, 7:57:52 AM1/1/21
to Axel Wagner, Alex Besogonov, golang-nuts
> 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 <axel.wa...@googlemail.com>:

Axel Wagner

unread,
Jan 1, 2021, 8:49:40 AM1/1/21
to Space A., Alex Besogonov, golang-nuts
On Fri, Jan 1, 2021 at 1:57 PM Space A. <reexi...@gmail.com> 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.

Space A.

unread,
Jan 1, 2021, 9:05:07 AM1/1/21
to Axel Wagner, Alex Besogonov, golang-nuts
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 <axel.wa...@googlemail.com>:

Axel Wagner

unread,
Jan 1, 2021, 9:31:35 AM1/1/21
to Space A., Alex Besogonov, golang-nuts
On Fri, Jan 1, 2021 at 3:04 PM Space A. <reexi...@gmail.com> 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.

Space A.

unread,
Jan 1, 2021, 10:12:57 AM1/1/21
to Axel Wagner, Alex Besogonov, golang-nuts
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 <axel.wa...@googlemail.com>:

Beka Westberg

unread,
Jan 1, 2021, 11:06:42 AM1/1/21
to golang-nuts
> 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.

robert engels

unread,
Jan 1, 2021, 1:45:02 PM1/1/21
to Space A., Axel Wagner, Alex Besogonov, golang-nuts
I hate to chime in here, but Go by the industry accepted definition - at least based on my 30+ years experience - is that Go is clearly an OOP language.

It has “instances” coupled with “behavior”. That is, given a struct instance I can call a method “on it” declared by its definition. Other OOP languages don’t require the definition and can create instance methods dynamically. 

This differs from a language like Assembly, C, Cobol (prior 2002), or Fortran (prior 2003).

For example, C has instances but no methods.

Space A.

unread,
Jan 1, 2021, 2:44:20 PM1/1/21
to robert engels, Axel Wagner, Alex Besogonov, golang-nuts
That's fine so we disagree on that. An you also seem to disagree on FAQ (I know you read it, that's for other readers):

Won't say how many years I have because I hate these talks and I used to think I'm still 20 yo =) But yea, I remember the times when "Assembly" was "Assembler".

пт, 1 янв. 2021 г. в 21:44, robert engels <ren...@ix.netcom.com>:

Space A.

unread,
Jan 1, 2021, 3:00:26 PM1/1/21
to Beka Westberg, golang-nuts
> 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 <bekawe...@gmail.com>:

robert engels

unread,
Jan 1, 2021, 3:28:19 PM1/1/21
to Space A., Beka Westberg, golang-nuts
You can write Java (or any other OOP with inheritance) using composition rather than inheritance. Much of the Java stdlib uses both. It can be argued that most usages of anonymous inner classes are composition rather than inheritance.

Space A.

unread,
Jan 1, 2021, 3:52:18 PM1/1/21
to robert engels, Beka Westberg, golang-nuts
Composition is just a principle, which can be implemented on different layers by different ways. I'd say in Java you will be forced not only to follow OOP (with inheritance and all of that ofc) even if you don't need it, you will end up writing in some framework and that framework will become your language, rather than vanilla Java, unless you're doing simple examples for students. First question Go newcomers ask on forums which framework I should use for my application.



пт, 1 янв. 2021 г. в 23:27, robert engels <ren...@ix.netcom.com>:

robert engels

unread,
Jan 1, 2021, 4:51:49 PM1/1/21
to Space A., Beka Westberg, golang-nuts
Those concerns are unrelated. There are plenty of frameworks in Go as well. You can create frameworks without using inheritance.

Space A.

unread,
Jan 1, 2021, 6:06:44 PM1/1/21
to robert engels, Beka Westberg, golang-nuts
You keep replying with random sentences no matter what I say, just combining known words in random phrases. Okay, but please put me out of your list, cause I have better games to play.


сб, 2 янв. 2021 г. в 00:50, robert engels <ren...@ix.netcom.com>:
It is loading more messages.
0 new messages