Your patience is inspiring! Thank you!
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the
> You are repeatedly starting new threads, keeping the same subject as already
> existing ones.
> Don't do that please, if you respond to a certain topic keep the thread
> intact.
>
> That way all the conversation is in a single place.
What are you on about!? This is my second post on this lis
I have found this extremely useful (was posted on GitHub) and I post
this for any latecomers to this thread some time in the future:
https://github.com/golang/go/wiki/ExperienceReports#generics
Especially this document:
https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX
@Ian Lance Taylor, I feel I must apologize to you. I have just hunted
down every single mailing list post from you regarding the generics
issues and I have found that you have been extremely balanced and very
much protecting the Go philosophy and wanting to avoid any added
complexity etc.
I am sor
Oh, I almost forgot, it also clearly does not "have minimal impact on everybody
else", which is another proposal selection criteria. Go code becomes much more
complex to read and understand from all the examples I have seen.
You can even find several YouTube videos with people trying to analyze
I write this from my understanding of the "Proposal selection criteria", which
clearly states, that in order for a proposal to be accepted, it has to "address
an important issue for many people".
This is why I'm asking for real life problem examples, not theoretical ones.
I do not believe that
I'm sorry, but this is not real life problems. This is exactly the problem with
this proposal. It's based on nothing but small theoretical examples.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receivin
I have been arguing passionately against adding generics to Go because
I truly believe that it is going against the simplicity of Go and the
philosophy behind the design of Go.
I believe that the resilience of Go against unnecessary change is of
vital importance. The experience provided by Ken Tho
@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
> 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 o
@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
> 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
> 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
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 G
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 renam
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 functio
16 matches
Mail list logo
