No generic, part -2

[alex-coder]

Hello again, 

I apologize for being so intrusive. 

Where it is possible to read about the evaluations of labor and complexity for 

GO itself for different implementations to introduce generic in GO ?

Thank you.

[Axel Wagner]

The title of your message seems to indicate that you are looking for arguments not to implement generics. You should be aware that the proposal to add generics has been accepted, so the discussion of whether or not Go will get generics is answered. For better or for worse.

With that in mind: I am not aware of any extensive or formal evaluation like the one you are looking for. And I don't think it is common to do such an evaluation for any language change proposal in Go, beyond what individuals estimate for projects they take on and the Go team planning their workload. It is possible someone on the Go team (or someone else) has more data though.

The discussion went on for several years and included many of the people working on the official Go compiler. The consensus seems to be, that the work required is not unreasonable. I am not personally aware of any of them raising concerns about the workload (though I might have missed something and/or I might've not been aware that someone voicing a concern was working on the compiler, so take that with a grain of salt).

As for third-party implementations: In general, it is up to the respective projects if and how they want to implement language changes. Planning that is not usually done in the context of the Go project. That being said, over the past 3 years or so there was plenty of occasion for any third party implementer to voice any concerns. I am not personally aware of any of them doing so (same caveats as above).

My own uneducated guess is that implementing the design is not prohibitively difficult. The syntactical changes are very small. The type inference algorithm is fairly simple. And a simple implementation can instantiate the generic types and functions early in the frontend, without having to modify many internals. Generics are a big language change in terms of expressive power of the language and a language change in terms of amount of discussion to get it right. But I suspect in terms of changes to the spec and implementations, it will be a surprisingly small change.

I'm sorry for a whole lot of "I don't know" - and maybe someone who knows more will add more. But as someone who was pretty actively participating in the discussion for the past several years, I wanted to re-assure you that "it is too much work to implement" is not really a concern shared by many, as far as I can tell :)

--
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/64e6d441-3564-49ab-9f97-233eda3ea682n%40googlegroups.com.

[Tyler Compton]

I would also add that there was an old generics design draft based around contracts [1] that was not accepted for multiple reasons, but one was that it wasn't clear how the implementation could actually work. This suggests that implementation issues are definitely considered during the proposal process, even if they're considered more quietly than other issues.

1. https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEE%3DHbr%3D2HzsWA21GQdkXj33iqRJvT6jO_wHC-X-U1%3DBg%40mail.gmail.com.

[Ian Lance Taylor]

LIke others, I'm not quite sure what you are asking, but perhaps you
want to look at

https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-stenciling.md
https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-dictionaries.md
https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-gcshape.md

Ian

[alex-coder]

Hello,

Thank you for the answers.

Now I have something to read. :-)

So, sorry for my English.

Personally, I would add a dynamic dispatching into GO

and left language without generic in order to keep simplicity for GO

and to make life of the applied programmers easier :-)

What I'm looking for is the rationale behind the technical decision

to understand why the sort of decision has been taken.

Thank you again for the answers.

[Space A.]

There is no rationale. They decided, and they implemented. No one from Go team ever took the argument against it seriously because "community" demands, blabla. And because Russ Cox with friends written an academic paper so this is now a question of pure science. Write your own and they could listen. (No)

суббота, 13 марта 2021 г. в 10:07:44 UTC+3, alex-coder:

[Martin Schnabel]

(sorry space a, i didn't reply to list)

hi alex and space a.

as far as i know there is no reason that anybody has to write code with
generics when they are available. therefor i really don't understand the
negative mails to this list.

do you also want others not to use them? how would that help you? could
you please explain to me your personal gain if generics are not added to
go and not available to me and other users? many users have valid use
cases for generics and custom code generation to deal with them now.

i personally never had a reason to use imaginary numbers in go, they are
however part of the language as literals and accompanied by special
built-ins. should i care, do you?

please explain

> <https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-stenciling.md>
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-dictionaries.md
> <https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-dictionaries.md>
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-gcshape.md
> <https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-gcshape.md>
>
>
> Ian

>
> --
> You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts...@googlegroups.com

> <mailto:golang-nuts...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/golang-nuts/8abb7704-ae60-4085-a7d7-0a8f7534e35dn%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/8abb7704-ae60-4085-a7d7-0a8f7534e35dn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Jan Mercl]

On Sat, Mar 13, 2021 at 1:44 PM Martin Schnabel <m...@mb0.org> wrote:

> as far as i know there is no reason that anybody has to write code with
> generics when they are available. therefor i really don't understand the
> negative mails to this list.

That nonchalantly ignores that code is way more often read than written.

"Clever" use of preprocessing macros can make C code unreadable to
anyone other than its author unless learning the mindset behind the
macros. Symbols in the binary can have very little connection with the
symbols in the source code. Nice tar pit for transpiling/debugging
etc. I believe that's why Go does not have C macros or anything like
that.

The problem with generics is not the same, but it shares some of the
problems depicted above. The no more existing 1:1 symbol mapping is
the one I regret most by a wide margin. Goodbye easy and simple
grepping.

Good use of generics _will_ be good for Go, don't get me wrong about
this. But, when looking at random code in the wild, let me ask: What's
the ratio of poor vs good code one encounters at random?

And don't get me wrong the second time. I'm writing a lot of poor
code. Once I start using generics, my future self will be probably the
first one to curse me for that.

[Levieux Michel]

It's not because the arguments didn't appear numerous / convincing enough that they were not taken into account. You are just stating your incapacity to accept that you might be wrong, as anyone can, and that you cannot discuss something (clearly because you don't want to *discuss*, you want people to take everything you say for granted and absolute truth).

There have been many discussions and debates about generics (first as to whether they should be added at all, then as to how they should be implemented if ever they were), different proposals that were rejected after lots and lots of arguments on both + and - minus sides, up to where we are now.

If you are not okay with generics, so be it, but one - don't manipulate facts, and second - stop being that dogmatic and negative here, please, for the sake of all of us.

In advance, thanks for your time and consideration.

Cheers.

--

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/8abb7704-ae60-4085-a7d7-0a8f7534e35dn%40googlegroups.com.

[Space A.]

HI Martin,

as Jan already explained, you're not only writing code, you also reading it. And you have to understand what's written. At the same time you're not just coding in Go, you're using the whole ecosystem including libraries and tools. So the mantra "just don't use if you don't like'' does not work, every Go programmer will be forced to use generics, to read and at the end, to write that code.

Second question you may ask - yes it will be overused, in fact in the very first year everything will be flooded with bad code. Because it's a new toy and biggest change to the language in years, because it's a "smart" way of doing things (we are mature programmers, aren't we?), because "type safety" and "performance" and so on so forth.

сб, 13 мар. 2021 г. в 15:45, Martin Schnabel <m...@mb0.org>:

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/lC9Z9VZXPdM/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/c67e637e-6eea-de85-1d43-e2d775424044%40mb0.org.

[Space A.]

> There have been many discussions and debates about generics (first as to whether they should be added at all

That's simply not true, there have never been raised a discussion of whether they should be added or not. There wasn't even a poll or anything. So the question of whether this topic should be dropped completely (a lot of reasons why) has not been thought out.

> If you are not okay with generics, so be it, but one - don't manipulate facts

Where did I manipulate?

> stop being that dogmatic and negative here, please, for the sake of all of us

Why do you tell me what to do, what to say, or what to feel?

сб, 13 мар. 2021 г. в 16:17, Levieux Michel <mlevi...@gmail.com>:

[Axel Wagner]

I want to re-iterate: The discussion of whether or not generics will be added to Go has been going on for more than a decade. All arguments from all sides have gotten fair consideration. A decision was reached.

You might not agree with that decision. But saying that "there are no arguments" or that "arguments have been ignored" is simply and demonstrably false. I understand that it can be difficult to accept that other qualified people can come to different conclusions from you, based on the same available data. But it's simply going to happen. So please be mindful of how you communicate. And ideally, don't try to re-open this discussion with the same arguments that have already been heard. It took enough time and energy from everyone to reach a decision once.

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/CADKwOTedhgWhxdRgiocwfWumghD5eBWe8AvL0HUmxN1pB-LUDA%40mail.gmail.com.

[alex-coder]

Hello again.

Looks like I have the several problems. :-)

First one is my English, it seems my written explanations not properly describe my wishes.

Next one is that I have missed the already closed discussion and include my opinion in context

where it would be unnecessary.

So, of course, of course the initial point to include generic into GO was the customer wishes.

And moreover possible I should change my opinion after reading all the references provided. :-)

Thank all of you.

[Jan Mercl]

On Sat, Mar 13, 2021 at 3:31 PM 'Axel Wagner' via golang-nuts
<golan...@googlegroups.com> wrote:

> I want to re-iterate: The discussion of whether or not generics will be added to Go has been going on for more than a decade. All arguments from all sides have gotten fair consideration. A decision was reached.
>
> You might not agree with that decision. But saying that "there are no arguments" or that "arguments have been ignored" is simply and demonstrably false.

Not false at all. If you have more than one party, differing in
conflicting opinions on a subject and you make a final decision, you
_must_ ignore at least arguments of one of the parties. That's nothing
wrong. It's the only way to make the decision happen.

Would the decision have been to not introduce generics in Go, the
arguments of people advocating generics would have to be - in the end
- ignored.

> So please be mindful of how you communicate.

I would like to ask for the same - but not only from S.A.

[Axel Wagner]

On Sat, Mar 13, 2021 at 3:42 PM Jan Mercl <0xj...@gmail.com> wrote:

Not false at all. If you have more than one party, differing in
conflicting opinions on a subject and you make a final decision, you
_must_ ignore at least arguments of one of the parties.

We have different interpretations of "ignore". To me, "ignore" means "be unaware of or pretend they don't exist".

You seem to use it as "disagree about their validity or the weight they are given in the decision". That seems questionable to me.

[Jan Mercl]

On Sat, Mar 13, 2021 at 3:53 PM Axel Wagner
<axel.wa...@googlemail.com> wrote:

> We have different interpretations of "ignore". To me, "ignore" means "be unaware of or pretend they don't exist".
> You seem to use it as "disagree about their validity or the weight they are given in the decision". That seems questionable to me.

No, that's not what I think. Opinions are not objectively measurable
and are thus in principle equal. Qualified people (not sure how to
define them), beginners, whoever. The decision maker assigned
subjective weights to the differing opinions and, again, that's just
fine and the only way to get the decision.

In no way that means my opinions are better or worse than yours or
anyone else's. They just differ and there's nothing wrong about that
either.

[Axel Wagner]

On Sat, Mar 13, 2021 at 4:00 PM Jan Mercl <0xj...@gmail.com> wrote:

On Sat, Mar 13, 2021 at 3:53 PM Axel Wagner
<axel.wa...@googlemail.com> wrote:

> We have different interpretations of "ignore". To me, "ignore" means "be unaware of or pretend they don't exist".
> You seem to use it as "disagree about their validity or the weight they are given in the decision". That seems questionable to me.

No, that's not what I think. Opinions are not objectively measurable
and are thus in principle equal. Qualified people (not sure how to
define them), beginners, whoever. The decision maker assigned
subjective weights to the differing opinions and, again, that's just
fine and the only way to get the decision.

I agree. I still believe that using "ignore" is a misuse of how the word is commonly understood. But as long as it's clear that what you describe here is demonstrably what has happened, I guess it does not matter what word you prefer to use for that.

[Bruno Albuquerque]

FWIIW, I also agree that "ignore" makes no sense here. You might listen and think about several opinions/options and conclude that one of them is the best one. This does not mean you ignored all the others.

--

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/CAEkBMfEfpAvm6zPjGKqVGVfDSPPbVwpRdz3sn4njrBgZAG2sew%40mail.gmail.com.

[Space A.]

> The discussion of whether or not generics will be added to Go has been going on for more than a decade.

That's a lie. There has never been a question of "add it or not". It was always "we will add them" sooner or later.

сб, 13 мар. 2021 г. в 17:31, 'Axel Wagner' via golang-nuts <golan...@googlegroups.com>:

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGbr-1g2NgpZryQeFWMgDzEnwYTfTGMaorWBV34jgcELw%40mail.gmail.com.

[Axel Wagner]

On Sat, Mar 13, 2021 at 4:19 PM Space A. <reexi...@gmail.com> wrote:

> The discussion of whether or not generics will be added to Go has been going on for more than a decade.

That's a lie. There has never been a question of "add it or not". It was always "we will add them" sooner or later.

It is somewhat amusing, though ultimately frustrating, that for ten years people where misquoting the Go team to say they categorically reject generics and now that a decision has been made to add them, they are being misquoted as saying they will definitely add them, sooner or later.

Both are not true. The stance has always been (demonstrably since before the open sourcing of Go) that generics may come at some point, if they can figure out a way that gives value commensurate with their complexity. This messaging has been consistent.

Even for this specific push (which started with the contracts design) whenever Ian, Russ, Robert or anyone else on the Go team has been asked if generics will be added, the response has been a consistent "if we find an approach that gives value commensurate with their complexity. We are hopeful that this one does, but we will see". The first time anyone has actually said generics will be added was when the proposal was marked as accepted. And I wouldn't condone the use of "always" for "since about a month ago" any more than I would condone "they ignored arguments" to mean "they disagreed with arguments".

If you insist on calling me a liar again, I would appreciate it if you could provide a source showing that anything of what I wrote here is untrue. Though, to be frank, I don't really think there is much point to this discussion either way - you have already demonstrated in the past that you are at best difficult to have a productive conversation with.

[Jan Mercl]

On Sat, Mar 13, 2021 at 4:18 PM Bruno Albuquerque <b...@gmail.com> wrote:

> FWIIW, I also agree that "ignore" makes no sense here. You might listen and think about several opinions/options and conclude that one of them is the best one. This does not mean you ignored all the others.

You do not ignore the differing opinions before you make the decision.
The decision makes them ignored because you cannot not ignore them. If
you would still consider them you cannot make the decision.

The decision outcome of whether to adopt generics or not adopt
generics is _binary_, hence why I knowingly use "ignore" and it means
exactly what it says. Kinda Sophie's choice, if you will.

The process of reaching the decision, OTOH, does not ignore
arguments/opinions. That I've never said and I don't know why it would
be inferred by anyone.

Last attempt to clarify: You cannot please all the parties at the same
time with this kind of decision, one must realize/admit that's a
non-goal. However, from the POV of someone from the "losing" side,
his/her argument can be legitimely, but subjectively perceived as
ignored - even when it was not actually ignored during the process.

[Axel Wagner]

I don't think it is useful to quibble over the definition of "ignore". When I said it is demonstrably false that arguments have been ignored, I was assuming what I perceive to be the common definition: "refuse to take notice of or acknowledge; disregard intentionally. fail to consider (something significant)". Under this definition, that statement implies that arguments have not been given consideration, which would be false. They have been considered, they just where not actually followed.

If the statement was made using a different definition, that is fine - at least we've gotten that clarification, then. I just did not want there to be any misunderstandings about what actually happened. I didn't want to start a debate about the English language.

[Space A.]

You are a smart guy, one of the smartest I have ever talked to. But it looks like you somehow missed a very obvious thing. The people you mentioned (and most of the so-called Go team) AFAIK are Google employees. They work for a company and they are paid for the work they do. If, as you say, they spend so much time, literally years, keep replying "if we find an approach that gives value blablabla", how do you imagine anyone responsible for the process at the end say smth like: "Alright guys, after spending so many man-years we have few solutions, but we finally realized that we were moving in wrong direction, so now we gonna be dropping everything for the sake of better future of Go". Like c'mon? Read what's written, not just words and punctuation, it was a one way ticket (and managers knew it), if you start this process, start spending money and reporting man hours, you know that it will land somewhere.

And I repeat, there wasn't a (public) question or discussion or anything regarding should we drop this topic entirely.

сб, 13 мар. 2021 г. в 18:32, Axel Wagner <axel.wa...@googlemail.com>:

[Jan Mercl]

On Sat, Mar 13, 2021 at 4:43 PM 'Axel Wagner' via golang-nuts
<golan...@googlegroups.com> wrote:
>
> I don't think it is useful to quibble over the definition of "ignore". When I said it is demonstrably false that arguments have been ignored, I was assuming what I perceive to be the common definition: "refuse to take notice of or acknowledge; disregard intentionally. fail to consider (something significant)". Under this definition, that statement implies that arguments have not been given consideration, which would be false. They have been considered, they just where not actually followed.
>
> If the statement was made using a different definition, that is fine - at least we've gotten that clarification, then. I just did not want there to be any misunderstandings about what actually happened. I didn't want to start a debate about the English language.

I believe we are using the very same definition. What I'm failing at
is to explain the context.

I may invest in bitcoins, let's say.

One thing/opinion is that it may bring profit. The other is that I may
lose my money. When I decide to buy bitcoins as well if I decide to do
the opposite, I'm from that moment ignoring one of those opinions
because the decision has been made. I cannot keep considering both the
conflicting opinions. I _must_ from now on ignore one of them. Failing
to do that means no decision can be made.

Only the future can tell if that was a wise choice or not. And that's
exactly the same about Go and generics.

[Carla Pfaff]

On Saturday, 13 March 2021 at 15:31:05 UTC+1 Space A. wrote:

There wasn't even a poll or anything. So the question of whether this topic should be dropped completely (a lot of reasons why) has not been thought out.

It was already explained that Go development is not driven by polls or surveys: https://groups.google.com/g/golang-nuts/c/LEEuJPOg0oo/m/uGjSw4VGBgAJ

You were in the same thread, you should already know this.

[Axel Wagner]

On Sat, Mar 13, 2021 at 4:59 PM Space A. <reexi...@gmail.com> wrote:

You are a smart guy, one of the smartest I have ever talked to. But it looks like you somehow missed a very obvious thing. The people you mentioned (and most of the so-called Go team) AFAIK are Google employees. They work for a company and they are paid for the work they do.

I did not miss this.

 

If, as you say, they spend so much time, literally years, keep replying "if we find an approach that gives value blablabla", how do you imagine anyone responsible for the process at the end say smth like: "Alright guys, after spending so many man-years we have few solutions, but we finally realized that we were moving in wrong direction, so now we gonna be dropping everything for the sake of better future of Go".

The person responsible for the process (if there is any one person) is Russ. I would have expect him to say that, if it was his opinion. He has a good track record of acknowledging the arguments on all sides of the process and committing to a decision - even it if goes contrary to a previous statement of his.

Here is a recent example I was involved in. He originally said, in no uncertain terms, that `ETag`s will be supported when an `embed.FS` is served over `net/http`. When it became clear that we don't have a good design to make it happen, he admitted that it's unfortunate to break that promise, but it's better than ending with a bad design.

Even then, what you are saying doesn't make a lot of sense to me. If they spend many years saying "we may add generics, if we find a design that works", they seem to be perfectly set up to say "we didn't find one" to their hypothetical employer (to be clear: Their employer doesn't care). Like, if anything, what they said made it *more* plausible to just drop generics altogether if they don't like the design.

And, personally, I was in the room when the original contracts design was first shown externally (at the GopherCon 2018 contributor summit) and I talked to Ian and Robert (and others) about it. As far as I remember, they were pretty open about their intent to let this be the last attempt, which would either lead to a) generics landing in Go or b) generics actually being rejected (in the sense of "changing the FAQ entry to say 'there will never be generics in Go, because we've given up on finding a design that works'").

That is, I'm not just working from the actual literal words of everyone involved and every public statement any of them has ever made (which I heard) but also from actually talking to them, in person, asking them clarifying questions and interpreting their facial and body language.

Of course, you don't have to believe me about any of this. But I can categorically say that, as far as I can tell, your allegations that the decision to add generics was pre-made is baseless.

 

Like c'mon? Read what's written, not just words and punctuation

As a rule, I try to avoid speculating about intent. It is hard enough to interpret what people are actually directly saying, without speculating about their internal monologue.

For example, when the Go team said "we may add generics, if we find a design that works", you seemingly heard "we will add generics in the future" and many others seemingly heard "we will never add generics". If we need to allow for different people hearing logically opposite messages from the same words, running a public project seems intractable.

So, I really don't think we should take stock in anything but the actual words people said.

 

And I repeat, there wasn't a (public) question or discussion or anything regarding should we drop this topic entirely.

That is not correct. The possibility of rejecting the proposal (and thus likely rejecting generics altogether) was always part of the conversation.

[jake...@gmail.com]

This thread seems like it has devolved into a rehashing of the recent Generics, please go away! thread. This seems unfair to the original poster, who asked a simple , respectful, question in good faith, and seems to be satisfied with the answers he got. This tread is now so devolved that it would be hard for him to even ask a followup. I would respectfully suggest that those wanting to rehash the generic debate please continue on the  Generics, please go away! thread.

[I will no longer be following this thread]

- Jake

On Friday, March 12, 2021 at 10:30:49 AM UTC-5 alex-coder wrote:

Hello again, 

I apologize for being so intrusive. 

Where it is possible to read about the evaluations of labor and complexity for 

GO itself for different implementations to introduce generic in GO ?

Thank you.

[Space A.]

> Here is a recent example I was involved in. He originally said, in no uncertain terms, that `ETag`s will be supported when an `embed.FS` is served over `net/http`.

There is a huge difference between generics and some regular questions like `Etag` implementation, isn't it? In time, investments, "community demand", commitments to upper management, etc

And Russ didn't write academic paper regarding it (before accepting proposal in less than a month after it was published). =)

сб, 13 мар. 2021 г. в 19:39, Axel Wagner <axel.wa...@googlemail.com>:

[Martin Schnabel]

hi jan,

i mostly share your perspective, but i may be a bit more optimistic.

the language as-is can be used to write horrible code already (i know
because i did and still sometimes do). i am also sure that many will
"abstract prematurely" before they see the light and come to reason (i
will probably do the same, because it is part of the learning process).

but i also have trust in the go developers and community and they earned
it. i am optimistically certain that the go standard library will not
morph into an java-esque object-hell (as some others seem to fear), not
only because many of use would nag and complain as we do, but because
the developers set out with - or flocked to - this same ideal of less is
more.

on the other hand are valid use-cases currently covered by code
duplication, code generation, and empty interfaces. that would often
gain from a clear type signature in addition to the existing docs or
well vetted and battle tested data structure packages. how many project
have their own tree implementations with subtle bugs, that nobody had
time to properly review? how many ways are there to generate code? how
many copy and pasted blocks of code have missed a change in the last
line? i know i have read papers that quantify these types of errors (i
think it was from someone involved in the findbugs project in java
land). although i don't remember details, i know it was not pretty and
mirrored my own experience reading and writing code.

my argument is, that if you do not use generics in your own code, but
libraries used by you do, then you would still need to read the docs and
learn the api - not a big difference from that perspective.

in the best case we add some type-safety, avoid obscure code generation
scripts, error prone duplication and simplify some apis, all while
making some code more comfortable - and other code even possible to write.

in the worst case we have some inappropriately popular libraries and
frameworks that use generics, that we can decide to ignore as a company,
group or individual. i would argue that we already have them here and
there and they don't particularly rely on generics to exist.

i think that go is what it is, not because of the language spec, but
because of the people that use it as to write code. nobody is perfect,
but we have many brilliant people on this list with a whole lot of
experience. i learned to trust the decisions of the go developer team
and they earned my respect and gratitude. the reason anyone would freely
choose go to write code is tied to the ideas, works and decisions of
these some people. why would i stop having trust in them now?

[Axel Wagner]

On Sat, Mar 13, 2021 at 6:24 PM Space A. <reexi...@gmail.com> wrote:

There is a huge difference between generics and some regular questions like `Etag` implementation, isn't it? In time, investments, "community demand", commitments to upper management, etc

Indeed. That doesn't change the fact that Russ has a track record and I trust him.

 

And Russ didn't write academic paper regarding it

Apparently I missed something. I'm unaware of any papers by Russ.

 

(before accepting proposal in less than a month after it was published). =)

The proposal has been evolving and discussed for almost three years before that. The reason it got accepted in the space of a months is that it was only published as a proposal once the authors felt confident that the refinements they made in response to the public discussion were sufficient to make it acceptable. In particular, it has changed very little from the version they posted more than a year earlier. After three years of discussion, it would have been surprising if new flaws would have surfaced that made it intractable.

It is a testament to how thoroughly it was discussed, not an indication that it wasn't.

FWIW, if you only focus on the one-month period between the proposal getting posted and it being accepted, I am beginning to understand why you think there was never a possibility of it being rejected. It would mean you are unaware of the decade of discussion preceding it.

[David Skinner]

I considered generics so important to our workflow that I added it quite some time ago, Go is an implementation language, you may implement anything you like with it. If you do not like the way it does something, you can use it to create a different language, that is what real programmers do. And Go makes it very easy to do. When I first started, I was writing machine code in octal and years later could read hex dumps the way others could ASM. The real problem is that each person who implemented a generics solution did so lightly differently so the learning curve is steep and the talent pool is shallow. Having well-defined generics for everyone to use will greatly benefit the 10% who rolled their own solution and make it easier for newbies who must later maintain that code. Heaven helps those who have to read my obscure proprietary generics code.

The real problem is to be able to create useful abstractions. Packages should be orthogonal APIs, functions should be descriptive, RPCs should not have a plethora of microservices for no good reason. Modules and Generics are really great and wonderful and save time, but only if used wisely and correctly and only as needed. Modules introduced chaos, the dust will settle. Generics shall also introduce chaos, but then those who learn to use it wisely and effectively shall enjoy and productivity improvement, and then that dust will settle.

I have personal reasons to have great trust in the Go team. Go has solved a plethora of problems for me already.

[Ian Lance Taylor]

On Sat, Mar 13, 2021 at 7:19 AM Space A. <reexi...@gmail.com> wrote:
>
> > The discussion of whether or not generics will be added to Go has been going on for more than a decade.
> That's a lie. There has never been a question of "add it or not". It was always "we will add them" sooner or later.

Please remember the Go Community Code of Conduct
(https://golang.org/conduct) and be respectful and charitable when
discussing other people. You could call a statement like this a
"mistake," if you must. It is not a "lie." Using a word like that in
this context is not respectful. Please don't do it. Thanks.

In this case it is neither a lie nor a mistake. I've been working on
generics in Go for over ten years, on and off, and I can assure you
that, as Axel said, there was no guarantee that they would be added.

Ian

[Ian Lance Taylor]

On Sat, Mar 13, 2021 at 7:59 AM Space A. <reexi...@gmail.com> wrote:
>
> You are a smart guy, one of the smartest I have ever talked to. But it looks like you somehow missed a very obvious thing. The people you mentioned (and most of the so-called Go team) AFAIK are Google employees. They work for a company and they are paid for the work they do. If, as you say, they spend so much time, literally years, keep replying "if we find an approach that gives value blablabla", how do you imagine anyone responsible for the process at the end say smth like: "Alright guys, after spending so many man-years we have few solutions, but we finally realized that we were moving in wrong direction, so now we gonna be dropping everything for the sake of better future of Go". Like c'mon? Read what's written, not just words and punctuation, it was a one way ticket (and managers knew it), if you start this process, start spending money and reporting man hours, you know that it will land somewhere.

I understand that argument, but I don't believe that it accurately
describes the development of the language. The clearest way to see
that is by looking at counter-examples. There have been several
efforts to change the Go language in the past that have, to date,
failed to occur, despite people "spending money and reporting man
hours." For example, the multiple proposals that flowed out of
https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md.
None of them have been adopted.

The people who work on Go, including the managers, are aware of the
risks of "we've started this project so we must complete it."
Language development doesn't work that way. It's OK to realize that
some ideas just can't be made to work.

This is helped by the fact that most language changes don't require
much work to start out. For many years I was the only person working
on generics in Go, and I certainly wasn't doing it full time. Then
for several years it was Robert Griesemer and I, again not full time.
Today there are several people working on generics in Go, but that is
only because we got it to the point of a proposal that could be
accepted.

> And I repeat, there wasn't a (public) question or discussion or anything regarding should we drop this topic entirely.

There have been many public discussions on this mailing list as to
whether generics should be dropped entirely.

Ian

[Ian Lance Taylor]

On Sat, Mar 13, 2021 at 9:25 AM Space A. <reexi...@gmail.com> wrote:
>
> And Russ didn't write academic paper regarding it (before accepting proposal in less than a month after it was published). =)

There may be some confusion here. Are you referring to the
Featherweight Go paper (https://arxiv.org/abs/2005.11710)? Russ
wasn't involved with that. And it was written in early 2020, long
before the generics proposal was accepted.

Or is there some other paper that I am not aware of?

Ian

[Space A.]

Sorry, of course it's Robert, my mistake.

пн, 15 мар. 2021 г. в 05:30, Ian Lance Taylor <ia...@golang.org>:

[Space A.]

> For example, the multiple proposals that flowed out of
https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md.
None of them have been adopted.

I remember what was happening to "try" error handling proposal. It was withdrawn only because of active resistance by the community.

And what's happened to a new "generics" proposal, it also got a lot of critics but was "accepted" in less than a month after formal publication on github. As Russ said "No change in consensus". What does it mean? Who are these people who can change the consensus? How was it measured? A few days after Russ locked it, so nobody can even say a word against it if they wanted. So it looks very much that company management learned from "try" proposal.

пн, 15 мар. 2021 г. в 05:27, Ian Lance Taylor <ia...@golang.org>:

[Space A.]

Entropy tends to grow. Good things tend to become less good and even bad over time. This is how the Universe works. Does C++ become a better language by adding more and more features? What about Java? What makes you think that people who were behind other languages weren't doing the same as what "Go team" now trying to do? What's the difference? I really loved Java at the beginning.

пн, 15 мар. 2021 г. в 03:24, David Skinner <skinne...@gmail.com>:

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/3962fea5-0b98-47e9-af2f-94ffab9452fan%40googlegroups.com.

[Wojciech S. Czarnecki]

Dnia 2021-03-15, o godz. 15:08:22
"Space A." <reexi...@gmail.com> napisał(a):

> And what's happened to a new "generics" proposal, it also got a lot of critics

Apparently not that lot. Second (publicized) design was for me, and likely for many other "vocal critics", good enough. My personal (and fresh) acceptance stems from a simple fact that with current generics proposal I will be able to do what I've been doing before with code generators. So there is a clear gain - someone who will maintain my code will not be forced to analyze and maintain generators.

> A few days after Russ locked it, so nobody can even say a word against it if they wanted.

On this list, that is not locked by Russ, I do not see "massive disapproval of the community". Some people, including me, voiced concerns re expected clutter and re worsened legibility. But these are minor disturbances. We just will learn to read and visualize new meanings in the code.


--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE

[Ian Lance Taylor]

On Mon, Mar 15, 2021 at 5:08 AM Space A. <reexi...@gmail.com> wrote:
>
> > For example, the multiple proposals that flowed out of
> https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md.
> None of them have been adopted.
>
> I remember what was happening to "try" error handling proposal. It was withdrawn only because of active resistance by the community.
>
> And what's happened to a new "generics" proposal, it also got a lot of critics but was "accepted" in less than a month after formal publication on github. As Russ said "No change in consensus". What does it mean? Who are these people who can change the consensus? How was it measured? A few days after Russ locked it, so nobody can even say a word against it if they wanted. So it looks very much that company management learned from "try" proposal.

The design draft was put up for discussion for months before it became
a formal proposal. It was not new.

The formal proposal (https://golang.org/issue/43651) got 1784 thumbs
up and 123 thumbs down (and ten "confused"). Yes, there were critics.
But I think it is fair to say that the proposal has far more
supporters than critics.

The "no change in consensus" comment refers to the discussion after
the proposal was moved to "likely accept" status:
https://github.com/golang/go/issues/43651#issuecomment-772744198.
After it was marked as "likely accept", there was no change to the
consensus that it should be accepted. (Note that the "likely accept"
comment got 60 thumbs up and 0 thumbs down (and one "confused").)

None of this is anything like the "try" proposal
(https://golang.org/issue/32437), which had 318 thumbs up and 794
thumbs down (and 132 "confused").

Ian

[atd...@gmail.com]

I am in favor of the proposal but I think that accounting for popularity votes is not a good measure of things.

A lot of people are at various stages of their technical journey in computer science and engineering and there has to be a weight given to the more technical opinions that is not reflected in the github upvote/downvote system.

At one point, everyone would have upvoted that the earth was flat.

Just a note in passing :)

[Ian Lance Taylor]

On Mon, Mar 15, 2021 at 3:11 PM atd...@gmail.com <atd...@gmail.com> wrote:
>
> I am in favor of the proposal but I think that accounting for popularity votes is not a good measure of things.
> A lot of people are at various stages of their technical journey in computer science and engineering and there has to be a weight given to the more technical opinions that is not reflected in the github upvote/downvote system.
> At one point, everyone would have upvoted that the earth was flat.
>
> Just a note in passing :)

Yes. I am not saying that the proposal was adopted because it had
good support. I am arguing against the suggestion that the proposal
should not have been adopted because it had a lot of critics.

Ian

> On Monday, March 15, 2021 at 11:03:50 PM UTC+1 Ian Lance Taylor wrote:
>>
>> On Mon, Mar 15, 2021 at 5:08 AM Space A. <reexi...@gmail.com> wrote:
>> >
>> > > For example, the multiple proposals that flowed out of
>> > https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md.
>> > None of them have been adopted.
>> >
>> > I remember what was happening to "try" error handling proposal. It was withdrawn only because of active resistance by the community.
>> >
>> > And what's happened to a new "generics" proposal, it also got a lot of critics but was "accepted" in less than a month after formal publication on github. As Russ said "No change in consensus". What does it mean? Who are these people who can change the consensus? How was it measured? A few days after Russ locked it, so nobody can even say a word against it if they wanted. So it looks very much that company management learned from "try" proposal.
>>
>> The design draft was put up for discussion for months before it became
>> a formal proposal. It was not new.
>>
>> The formal proposal (https://golang.org/issue/43651) got 1784 thumbs
>> up and 123 thumbs down (and ten "confused"). Yes, there were critics.
>> But I think it is fair to say that the proposal has far more
>> supporters than critics.
>>
>> The "no change in consensus" comment refers to the discussion after
>> the proposal was moved to "likely accept" status:
>> https://github.com/golang/go/issues/43651#issuecomment-772744198.
>> After it was marked as "likely accept", there was no change to the
>> consensus that it should be accepted. (Note that the "likely accept"
>> comment got 60 thumbs up and 0 thumbs down (and one "confused").)
>>
>> None of this is anything like the "try" proposal
>> (https://golang.org/issue/32437), which had 318 thumbs up and 794
>> thumbs down (and 132 "confused").
>>
>> Ian
>

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/932a39b7-be1b-4c15-b7c8-f99fce730b0en%40googlegroups.com.

[Jeremy French]

I was really trying not to weigh in here, mostly because it's a decision that has been decided, so there's not a lot of point in continuing the discussion, and yesterday it seemed like the thread would die, yet... it continues.

For context, I was against the generics proposal, primarily because it would make *my* life more complicated, while not providing *me* that much benefit.  I raised the concerns I had, especially in regards to the "if you don't like it, don't use it" arguments. I participated in a couple conversations on this mailing list.  In the end, I was fairly convinced that there were others in the community (and the community as a whole) who would benefit from the change far more than what it would cost me, and resigned myself to the change.

All of that is just to establish my bona fides.  If I were inclined to be biased on this topic, it would be against the Go team, not in their favor.  

And yet, I can say unequivocally that any suggestion that the Go team has railroaded this proposal through, or has ignored the concerns of its user base, is pure fiction.  Every single concern or question I've seen raised has been addressed respectfully and at face value - even, I would say - several concerns or complaints on this side of the argument that perhaps reasonably could have been scoffed at or dismissed as just stupid.  They have been respectful and attentive at every turn.  I don't necessarily agree or like the decision they made, but these character assassinations against them or implications that they are subject to corruption from their corporate parent have no supporting evidence that I've seen, including any presented in this thread.

It seems pretty clear that they are passionate about the health and longevity of the project, and are in the unenviable position of having to make a decision that is guaranteed to make some people angry no matter what they decide.  But in the end, it is their call to make, and they made it the best way they could think of to do so.  You can't ask any more than that.

[Robert Engels]

Very well said. 

On Mar 15, 2021, at 7:04 PM, Jeremy French <ibi...@gmail.com> wrote:

I was really trying not to weigh in here, mostly because it's a decision that has been decided, so there's not a lot of point in continuing the discussion, and yesterday it seemed like the thread would die, yet... it continues.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/6a690d7a-1f20-42d3-8528-94b80891d239n%40googlegroups.com.

[Jan Mercl]

On Mon, Mar 15, 2021 at 11:03 PM Ian Lance Taylor <ia...@golang.org> wrote:

> The formal proposal (https://golang.org/issue/43651) got 1784 thumbs
> up and 123 thumbs down (and ten "confused"). Yes, there were critics.
> But I think it is fair to say that the proposal has far more
> supporters than critics.

I think it should be noted that:

- No one knows how many of the voters don't actually use Go or are Go
novices. IOW, the statistical properties of the voting population are
not known to be the same or even reasonably similar within a certain
margin to those of the population of Go programmers.
- We can create a hypothesis, that if only people coding in Go for
more than N years, the results may get very different or even
inverted. Due to the above we cannot decide the validity of the
hypothesis. The validity could be, or could have been somehow
estimated by asking a smaller corpus of well known Go developers. Not
meant as a decisive body. Just to get some more reliable data. The
Github votes are, technically speaking, not distinguishable from
noise, ad hoc brigading, etc.
- Regardless of the endless promotion of inclusiveness, the voting
using the service of a single and notoriously controversial provider
of said service ignores, or excludes if you will, people not using
that service for any reason, not only the one I just mentioned.

In the light of the above, it's a bit surprising that the voting
results are even seriously mentioned in this discussion.

----

Some may have mistakenly inferred I'm against generics. I'm not. But
I'm neither in favor of them. Yet. Ask me some years after they are
released.

[wilk]

On 16-03-2021, Robert Engels wrote:

> Very well said.=20

+1

--
wilk

[wilk]

On 15-03-2021, Ian Lance Taylor wrote:

> On Mon, Mar 15, 2021 at 3:11 PM atd...@gmail.com <atdiar-Re5JQEe...@public.gmane.org> wrote:
>>
>> I am in favor of the proposal but I think that accounting for popularity votes is not a good measure of things.
>> A lot of people are at various stages of their technical journey in computer science and engineering and there has to be a weight given to the more technical opinions that is not reflected in the github upvote/downvote system.
>> At one point, everyone would have upvoted that the earth was flat.
>>
>> Just a note in passing :)
>
> Yes.

Please don't fall into the trap !

You're truly impressive how you have been so attentive to all the
critics. Keep it !

I believe we've all learned a lot since one decade of discussion about
this.

Thanks

> I am not saying that the proposal was adopted because it had
> good support. I am arguing against the suggestion that the proposal
> should not have been adopted because it had a lot of critics.
>
> Ian

--
wilk

[Space A.]

> The design draft was put up for discussion for months before it became
a formal proposal.  It was not new.

There is always a "discussion", most people (as well as I) will look only at the final version of proposal, if and when they have time. And what's the point of having formal proposals if you don't respect that process? Once you published, please notify everyone and give them time to come back with critics. Or just do what you do, but don't tell me or anyone that there is any "community" behind, "decade of discussion" and all that stuff.

> The formal proposal (https://golang.org/issue/43651) got 1784 thumbs
up and 123 thumbs down (and ten "confused").  Yes, there were critics.
But I think it is fair to say that the proposal has far more
supporters than critics.

LOL. You LOCKED that issue (including emojis!). You locked because Russ or whoever is responsible for the process in the company, was afraid that it will be like with "try" proposal. So please don't. And are you saying that "consensus" is how many emojis "up", "down" or "confused" were collected? You know that it's pretty easy to cheat with that system right?

вт, 16 мар. 2021 г. в 01:03, Ian Lance Taylor <ia...@golang.org>:

[Axel Wagner]

On Tue, Mar 16, 2021 at 12:00 PM Space A. <reexi...@gmail.com> wrote:

There is always a "discussion", most people (as well as I) will look only at the final version of proposal, if and when they have time. And what's the point of having formal proposals if you don't respect that process? Once you published, please notify everyone and give them time to come back with critics. Or just do what you do, but don't tell me or anyone that there is any "community" behind, "decade of discussion" and all that stuff.

This seems very dismissive of the many members of the community which *did* invest the time and energy to discuss the design for the past years. When the contracts design was announced in 2018, the process was explained. Including the fact that it is a draft, which will see several revisions, that this process will likely take a couple of years and how we can participate in it. Many of us have seen that announcement and understood it for what it was and thus - even if (like me) they were opposed to the idea of generics in Go - decided to participate in it to do their best to ensure the outcome was a good design or a rejection.

So, no offense, but I don't understand how you could in good faith argue that the community was not involved, the process not respected or the intention not announced. It was announced on the largest Go conference in the world, accompanied by a blog post and several threads on golang-nuts and golang-dev. With regular updates on the progress, again at most of the large Go conferences, the blog, on this mailing list, several times on the largest community-run Go podcast and in basically every medium I can think of.

If you didn't want or didn't have the time to participate in the process, that's certainly unfortunate. But I believe it is fair to say that the Go team went above and beyond to make the process as broadly accessible and known as they can.

And are you saying that "consensus" is how many emojis "up", "down" or "confused" were collected? You know that it's pretty easy to cheat with that system right?

Not to point out the obvious, but you where the first person in this thread to ask for a poll. And Ian has been pretty clear about the flaws of that idea and that it's not how the Go project is run.

Again, it is very hard to interpret your words and actions in good faith here.

[Space A.]

> This seems very dismissive of the many members of the community which *did* invest the time and energy to discuss the design for the past years. When the contracts design was announced in 2018, the process was explained. Including the fact that it is a draft, which will see several revisions, that this process will likely take a couple of years and how we can participate in it. Many of us have seen that announcement and understood it for what it was and thus - even if (like me) they were opposed to the idea of generics in Go - decided to participate in it to do their best to ensure the outcome was a good design or a rejection.

That's absolutely up to you, but some of us (including myself) can't invest so much time because we have to earn money for living.

> Not to point out the obvious, but you where the first person in this thread to ask for a poll. And Ian has been pretty clear about the flaws of that idea and that it's not how the Go project is run.

I didn't ask for the poll, I just stated that there was no poll, as simple as that.

вт, 16 мар. 2021 г. в 15:05, Axel Wagner <axel.wa...@googlemail.com>:

[wilk]

On 16-03-2021, Space A. wrote:

>> This seems very dismissive of the many members of the community which
> *did* invest the time and energy to discuss the design for the past years.
> When the contracts design was announced in 2018

><https://blog.golang.org/go2draft>, the process was explained. Including

> the fact that it is a draft, which will see several revisions, that this
> process will likely take a couple of years and how we can participate in
> it. Many of us have seen that announcement and understood it for what it
> was and thus - even if (like me) they were opposed to the idea of generics
> in Go - decided to participate in it to do their best to ensure the outcome
> was a good design or a rejection.
>
> That's absolutely up to you, but some of us (including myself) can't invest
> so much time because we have to earn money for living.

Every body need to earn money for living. Generics will maybe help for
that. It's why we was a lot (in the community) to invest time discussing
this since years. I thanks Alex and others who have contributed a lot
more time than me. We should respect all this work.

--
wilk

[Axel Wagner]

On Tue, Mar 16, 2021 at 1:24 PM Space A. <reexi...@gmail.com> wrote:

That's absolutely up to you, but some of us (including myself) can't invest so much time because we have to earn money for living.

As I said, I understand that reality. It is unfortunate, but given that language design takes time and effort, I don't really know a better way to do it, that makes it accessible to people who don't have those resources available.

 

I didn't ask for the poll, I just stated that there was no poll, as simple as that.

While true, that makes your complaint even harder to understand to me.

If your complaint was that there should have been a poll, it would be rooted in a true observation - there was none. And we could then talk about why we don't believe polls are a good way to do language design.

If your complaint was that you didn't have time to participate in the discussion, that's also rooted in a true observation. But I don't understand what you would have expected the Go team to do about it. It is hardly their fault that you are forced by the system we live in to deprioritize Go language development.

(To be clear, your original claim was that there *was* no discussion - which is at least easy to address, because it's clearly not true. There was over three years of active discussion on this)

I simply don't understand what you expected to happen. As I said, I don't really know a way to include people that both a) dosen't require any time on their part and b) isn't a poll, with all its methodological problems.

[Space A.]

> (To be clear, your original claim was that there *was* no discussion - which is at least easy to address, because it's clearly not true. There was over three years of active discussion on this)

No, and I can repeat, there was no (public) discussion on whether the idea of generics in Go should be completely dropped. It *was* always a "discussion" of how to improve and implement generics in a Go way, but not of generics themselves as something to be avoided by all means.

My main complaint is that I think what Go team is doing right now is destructive and goes against Go core values, such as simplicity over cleverness. And despite being claimed Go team doesn't know a way of improving language, other than adding features.

вт, 16 мар. 2021 г. в 16:25, Axel Wagner <axel.wa...@googlemail.com>:

[Axel Wagner]

On Tue, Mar 16, 2021 at 2:51 PM Space A. <reexi...@gmail.com> wrote:

No, and I can repeat, there was no (public) discussion on whether the idea of generics in Go should be completely dropped. It *was* always a "discussion" of how to improve and implement generics in a Go way, but not of generics themselves as something to be avoided by all means.

Okay. I can only repeat that "we are not going to add generics" was the most likely consequence of "we don't accept this design". So given that there was a discussion whether or not we want to accept this design (or what modification of it we might accept) constituted a discussion on if we want to add generics.

That's the process for Go language development. There is a proposal and it either gets accepted or refined or rejected. Generics where no different in this regard - except maybe in the sense that there was more discussion than usual and the proposal was more thoroughly discussed and refined before being filed. But note that it's not uncommon for language changes to be discussed and refined before a proposal is filed either.

 

My main complaint is that I think what Go team is doing right now is destructive and goes against Go core values,

So, AIUI, the core complaint is that they are disagreeing with you on this. That's understandably frustrating, but also a natural part and frequent outcome of discussions. It's not really a complaint that can be addressed, because if they agreed with you, someone else could have the same complaint about *not* adding generics.

ISTM you just have to come to terms with the fact that not everyone will always agree with you.

[Space A.]

Go will loose its uniqueness and values, will never become a next big thing. No cross platform GUI, no Android, and browsers (GopherJS is more dead than alive, WASM idk) is also a big question. It will be a "bad copy" of Java or other mature languages (with better and more powerful generics and lots of other built-in capabilities), niche tool for cli, devops and microservices (until the fashion will turn into monoliths or whatever this spiral thing brings up again). Now think where all your investments in language skills be in next few years.

вт, 16 мар. 2021 г. в 16:06, wilk <wi...@flibuste.net>:

--
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/lC9Z9VZXPdM/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/s2qag8%24i2a%241%40ciao.gmane.io.

[CreateSpaceMap]

You have a unique thought, you would consider V language if that is what you have been thinking about.

[CreateSpaceMap]

Sorry, I might sound a little blunt but this pique my curiosity, how much time have you invest in Go and what do you earn for a living? You can assure Go didn't just happen to be popular, they are built with blood and sweat, what have you done along the way? Countless of developers accept Generics that include me, not so bad when you already knew how other programming language and industry have evolved in the last 10 to 20 years.

Honestly, it's your own space and time problem if you don't have time to invest in change because you didn't want to be change or the web didn't evolve. You should step out of your comfortable zone or space and do what you could improve your community, not the other way round to please you, it doesn't happen in this planet. Generics is only a small part in Go with minimal impact compare to other programming languages with ton of pain to relearn.

You have probably heard V language has generic?

[Space A.]

One more person pro-generics switching the topic to my personality and telling me what to do and what my problem is.

вт, 16 мар. 2021 г. в 18:26, CreateSpaceMap <create...@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/lC9Z9VZXPdM/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/2f1b571a-17fe-42fa-8f33-7faa0211c7dfn%40googlegroups.com.

[Ian Lance Taylor]

On Mon, Mar 15, 2021 at 11:10 PM Jan Mercl <0xj...@gmail.com> wrote:
>
> - We can create a hypothesis, that if only people coding in Go for
> more than N years, the results may get very different or even
> inverted. Due to the above we cannot decide the validity of the
> hypothesis. The validity could be, or could have been somehow
> estimated by asking a smaller corpus of well known Go developers. Not
> meant as a decisive body. Just to get some more reliable data. The
> Github votes are, technically speaking, not distinguishable from
> noise, ad hoc brigading, etc.

I just want to note that we did in fact reach out to a number of
experienced Go developers with early versions of the design draft to
get their feedback before we published it
(https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#acknowledgements)
(we reached out to other people not mentioned who did not have time to
participate).

> - Regardless of the endless promotion of inclusiveness, the voting
> using the service of a single and notoriously controversial provider
> of said service ignores, or excludes if you will, people not using
> that service for any reason, not only the one I just mentioned.
>
> In the light of the above, it's a bit surprising that the voting
> results are even seriously mentioned in this discussion.

Fair enough. I cite numbers like these, and the comments on the Go
survey, because they are the only numbers I have. But you're clearly
right that they are problematic.

Ian

[Ian Lance Taylor]

On Tue, Mar 16, 2021 at 4:00 AM Space A. <reexi...@gmail.com> wrote:
>
> > The design draft was put up for discussion for months before it became
> a formal proposal. It was not new.
>
> There is always a "discussion", most people (as well as I) will look only at the final version of proposal, if and when they have time. And what's the point of having formal proposals if you don't respect that process? Once you published, please notify everyone and give them time to come back with critics. Or just do what you do, but don't tell me or anyone that there is any "community" behind, "decade of discussion" and all that stuff.

I think we've been clear as we were able about the process over the
past several years. I'm sorry that it wasn't clear to you.

> > The formal proposal (https://golang.org/issue/43651) got 1784 thumbs
> up and 123 thumbs down (and ten "confused"). Yes, there were critics.
> But I think it is fair to say that the proposal has far more
> supporters than critics.
>
> LOL. You LOCKED that issue (including emojis!). You locked because Russ or whoever is responsible for the process in the company, was afraid that it will be like with "try" proposal. So please don't. And are you saying that "consensus" is how many emojis "up", "down" or "confused" were collected? You know that it's pretty easy to cheat with that system right?

Russ locked the proposal issue after it was accepted.

Ian

[Ian Lance Taylor]

On Tue, Mar 16, 2021 at 6:51 AM Space A. <reexi...@gmail.com> wrote:
>
> > (To be clear, your original claim was that there *was* no discussion - which is at least easy to address, because it's clearly not true. There was over three years of active discussion on this)
>
> No, and I can repeat, there was no (public) discussion on whether the idea of generics in Go should be completely dropped. It *was* always a "discussion" of how to improve and implement generics in a Go way, but not of generics themselves as something to be avoided by all means.

I'm sorry, but that simply isn't the case. Many different people at
many different times suggested that the idea of adding generics should
be dropped. Those ideas were discussed, supported, opposed, and so
forth. It's been a long discussion over many years.

Ian

[Ian Lance Taylor]

On Tue, Mar 16, 2021 at 7:34 AM Space A. <reexi...@gmail.com> wrote:
>
> Go will loose its uniqueness and values, will never become a next big thing. No cross platform GUI, no Android, and browsers (GopherJS is more dead than alive, WASM idk) is also a big question. It will be a "bad copy" of Java or other mature languages (with better and more powerful generics and lots of other built-in capabilities), niche tool for cli, devops and microservices (until the fashion will turn into monoliths or whatever this spiral thing brings up again). Now think where all your investments in language skills be in next few years.

All of those things could certainly come to pass.

However, I'm very skeptical that adding generics to the language will
cause them to come to pass.

And, fortunately, even with generics I believe that Go will remain
significantly simpler than languages like Java or C++, with a
correspondingly smaller investment in language skills.

Ian

[Kevin Chadwick]

I do have one concern this touches on wrt tinygo. I do not know what googles stance is in regard to go on microchips but they seem to be supporting it financially. When raised before, it was stated that it had not been considered or discussed with the relevant parties. Java had the original aim of running everywhere, it failed on micros. Go could accomplish that aim

My concern (an uneducated concern) is that considering a micro running currently compatible parts of the stdlib with gc set to none and using global variables for reliable memory consumption. *Might* Generics adoption within the stdlib make more of it unusable (assuming generics poses a problem, it might not). I assume that it would not affect wasm.

This in itself is not a game stopper as I believe go is a useful language without gc or the stdlib. I do think that micros are important enough to be considered, however. Perhaps not important enough in the footprint of google services but maybe those that need Generics.

If I recall correctly. I may have raised it on the tinygo slack and the response was that nothing looked too problematic from what had been seen.

In any case, it might be worth the go team understanding what does and doesn't cause problems for tinygo?

[Axel Wagner]

On Wed, Mar 17, 2021 at 10:47 AM Kevin Chadwick <m8il...@gmail.com> wrote:

My concern (an uneducated concern) is that considering a micro running currently compatible parts of the stdlib with gc set to none and using global variables for reliable memory consumption.

When I look at the Go language feature page of TinyGo, I don't think that GC is the only or largest hindrance to using it with normal Go programs. TBQH I'm always surprised that people call it a Go implementation - it certainly uses Go syntax, but it's IMO not even close to complete.

 

*Might* Generics adoption within the stdlib make more of it unusable (assuming generics poses a problem, it might not).

No. Generics can be implemented as a purely compile-time feature.

This in itself is not a game stopper as I believe go is a useful language without gc or the stdlib. I do think that micros are important enough to be considered, however. Perhaps not important enough in the footprint of google services but maybe those that need Generics.

If I recall correctly. I may have raised it on the tinygo slack and the response was that nothing looked too problematic from what had been seen.

In any case, it might be worth the go team understanding what does and doesn't cause problems for tinygo?

--
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/58C57DC6-716D-4BD5-B32A-5492417A7302%40gmail.com.

[Space A.]

> Russ locked the proposal issue after it was accepted.

Proposal published on 12 Jan

Russ "accepted" it on 10 Feb

Russ locked it on 20 Feb with

" That is our usual way of using issues, but this issue continues to gather comments that are not relevant to tracking the work of implementing the proposal. "

Yep, sure.

ср, 17 мар. 2021 г. в 02:08, Ian Lance Taylor <ia...@golang.org>:

[Space A.]

Can you provide any proof that there was an open public discussion?

ср, 17 мар. 2021 г. в 02:12, Ian Lance Taylor <ia...@golang.org>:

[Wojciech S. Czarnecki]

Dnia 2021-03-17, o godz. 14:27:51
"Space A." <reexi...@gmail.com> napisał(a):

> Can you provide any proof that there was an open public discussion?

Can't you search for yourself? When I submitted my rough counterproposal there
were already over 50 others linked at Team's (compile contracts one).
Wasn't it a discussion then?

Talking current proposal: brackets in syntax are the most visible effect of the Team
having open discussion with "us". "We" barked at "unbearable parenthesosis" and
"our" voice was taken into account.

So please stop stretching this thread — all its yaks already are hairless.

--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE

[Space A.]

I don't think Java failed on micros, for instance look at JavaCard, a lot of SIM-cards are running applets based on it. SIM cards can be a dying technology on itself, but still, I think there was a huge success. Not sure about other "small places" because I never touched them in my work.

With regards to TinyGo, it's interesting. I also heard that they are sponsored by Google. Which is good. However Richard Musiol, the creator of GopherJS and person responsible for WebAssembly in Go compiler

https://docs.google.com/document/d/131vjr4DH6JFnb-blm_uRdaC0_Nv3OUwjEY5qVCxCup4/edit#heading=h.mjo1bish3xni

in one of his comments on gihub clearly said that he is not paid or in any form financially supported. And he's doing his work in spare time. I just don't get it.

There is gioui project which aim at implementing crossplatform GUI without relying on C libs, and they have already showcased very promising results. Any support from Google? Like some symbolic $100 bucks check per month? You knew the answer.

I'm pretty sceptical about TinyGo. It implements a subset of language, and I tried it for my WASM project, but didn't find it suitable at all. If I only wanted a small part of Go, I'd choose C.

ср, 17 мар. 2021 г. в 12:48, Kevin Chadwick <m8il...@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/lC9Z9VZXPdM/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/58C57DC6-716D-4BD5-B32A-5492417A7302%40gmail.com.

[Space A.]

I can, and I searched, and right answer is there was no open public discussion on dropping Generics proposal entirely, only "counterproposals". But it's a no brainer that if you propose anything other than "No Generics, never" you will end up with some form of them.

ср, 17 мар. 2021 г. в 14:57, Wojciech S. Czarnecki <oh...@fairbe.org>:

--
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/lC9Z9VZXPdM/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/20210317125511.46a0698d%40xmint.

[Robert Engels]

Java was actually very successful on micros. It is running on billions of IOT and smart card devices - and android on SoC.

> On Mar 17, 2021, at 4:47 AM, Kevin Chadwick <m8il...@gmail.com> wrote:
>
> 

> --
> 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/58C57DC6-716D-4BD5-B32A-5492417A7302%40gmail.com.

[Kevin Chadwick]

On 3/17/21 12:11 PM, Space A. wrote:
> I don't think Java failed on micros, for instance look at JavaCard, a lot of
> SIM-cards are running applets based on it. SIM cards can be a dying technology
> on itself, but still, I think there was a huge success. Not sure about other
> "small places" because I never touched them in my work.
>

I didn't know about JavaCard. Quite hard to gauge it's suitability to mmuless
systems, nevermind particular ones. I don't believe Pythons variant is suitable
but JavaCard might be. I don't want to write Java though anyway. I'm also not a
fan of Java's security record either.

> With regards to TinyGo, it's interesting. I also heard that they are sponsored
> by Google. Which is good. However Richard Musiol, the creator of GopherJS and
> person responsible for WebAssembly in Go compiler
> https://docs.google.com/document/d/131vjr4DH6JFnb-blm_uRdaC0_Nv3OUwjEY5qVCxCup4/edit#heading=h.mjo1bish3xni
> <https://docs.google.com/document/d/131vjr4DH6JFnb-blm_uRdaC0_Nv3OUwjEY5qVCxCup4/edit#heading=h.mjo1bish3xni>
> in one of his comments on gihub clearly said that he is not paid or in any form
> financially supported. And he's doing his work in spare time. I just don't get it.
>
> There is gioui project which aim at implementing crossplatform GUI without
> relying on C libs, and they have already showcased very promising results. Any
> support from Google? Like some symbolic $100 bucks check per month? You knew the
> answer.
>
> I'm pretty sceptical about TinyGo. It implements a subset of language, and I
> tried it for my WASM project, but didn't find it suitable at all. If I only
> wanted a small part of Go, I'd choose C.

Looks like JavaCard implements a far smaller subset than tinyGO according to
their site. If you have 256k Ram and that is a generous option, then it is going
to be a subset. I thought it was surprising how much of the stdlib is said to be
working. C compatibility is also important that both tinyGo and Zig offer. I
want to get away from C as much as possible! I shouldn't have to do so much like
writing reasonably memory safe array handling functions to be confident in my
codes security. Because C can't be arsed to offer safer compile options.

[Kevin Chadwick]

On 3/17/21 10:02 AM, Axel Wagner wrote:
> When I look at the Go language feature page of TinyGo

> <https://tinygo.org/lang-support/>, I don't think that GC is the only or largest

> hindrance to using it with normal Go programs. TBQH I'm always surprised that
> people call it a Go implementation - it certainly uses Go syntax, but it's IMO
> not even close to complete.

I'm actually happiest with the language part of GO. Not necessarily so much, the
implementation. It has the potential to make me happy, anyway.

"https://tinygo.org/lang-support/stdlib/"

>  
>
> *Might* Generics adoption within the stdlib make more of it unusable
> (assuming generics poses a problem, it might not).
>
>
> No. Generics can be implemented as a purely compile-time feature

> <https://github.com/golang/proposal/blob/master/design/generics-implementation-stenciling.md>.

So, like I said, if you avoid using parts of the stdlib. Or are you saying that
existing parts of the stdlib will not migrate to using Generics. If Generics has
any affect on the above link then I would have a conflict of interest in that I
hope they would migrate generally in order to avoid empty interface use.

[Kevin Chadwick]

> I'm actually happiest with the language part of GO. Not necessarily so much, the> implementation. It has the potential to make me happy, anyway.> >
"https://tinygo.org/lang-support/stdlib/"

I should clarify.

My interest is purely memory safety and ease of porting existing vendor provided
C code etc..

stdlib is a bonus, but attractive in some cases.

[Axel Wagner]

On Wed, Mar 17, 2021 at 2:36 PM Kevin Chadwick <m8il...@gmail.com> wrote:

>     *Might* Generics adoption within the stdlib make more of it unusable
>     (assuming generics poses a problem, it might not).
> No. Generics can be implemented as a purely compile-time feature
> <https://github.com/golang/proposal/blob/master/design/generics-implementation-stenciling.md>.

So, like I said, if you avoid using parts of the stdlib. Or are you saying that
existing parts of the stdlib will not migrate to using Generics.

No, I am saying that your assumptions that generics pose a problem is wrong. There is no technical reason that would prevent the authors of TinyGo to implement them, without too much trouble. Certainly far less trouble than other language features they already support.

AIUI that's also the answer you got from them, so  I don't understand the confusion.

 

If Generics has
any affect on the above link then I would have a conflict of interest in that I
hope they would migrate generally in order to avoid empty interface use.

--
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/b91bf116-a23b-8fdf-468b-cb83897d0a5b%40gmail.com.

[Kevin Chadwick]

On 3/17/21 1:57 PM, Axel Wagner wrote:
> No, I am saying that your assumptions that generics pose a problem is wrong.
> There is no technical reason that would prevent the authors of TinyGo to
> implement them, without too much trouble. Certainly far less trouble than other
> language features they already support.

That is not what you said or meant and I didn't make an assumption.

>
> AIUI that's also the answer you got from them, so  I don't understand the confusion.

s/confusion/question/

That you ignored

I was basically asking if TinyGo and Go should communicate more. I assume from
what you have said, that you disagree.

[Axel Wagner]

On Wed, Mar 17, 2021 at 3:22 PM Kevin Chadwick <m8il...@gmail.com> wrote:

That is not what you said or meant and I didn't make an assumption.

No offense, but you did use the words "assuming generics poses a question". Apologies that I misunderstood, but I was trying to respond to that.

 

I was basically asking if TinyGo and Go should communicate more. I assume from
what you have said, that you disagree.

I don't. I have no opinions on that one way or another. As I said, I was simply trying to state that I don't believe there is any reason for concern in regards to TinyGo being able to implement generics.

I guess that does imply I don't see a reason for the TinyGo developers and the Go team to have a conversation about this specifically. But FWIW, a) I believe the TinyGo developers are perfectly capable to contact the Go team if they see the need (and vice-versa) and b) Ayke van Laëthem, the main developer of TinyGo, is explicitly called out in the acknowledgment on the design doc, so it seems fair to conclude that a conversation still happened.

 

--
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/e92fef38-42c9-e68f-e42f-813a961d0063%40gmail.com.

[Space A.]

> I want to get away from C as much as possible! I shouldn't have to do so much like
writing reasonably memory safe array handling functions to be confident in my

codes security. Because C can't be arsed to offer safer compile options.

Yes, I understand that in your projects using tinyGo instead of Java/C might be the best possible option. It's just in my own case it doesn't fit. And my scepticism is more about using tinyGo as a WASM compiler, when people for no real reason trying to save few megs of binary size like we are back in 90th.

And yes, of course in projects like tinyGo and in many others generics will add a significant cost to development. It's feasible, because it's not a rocket science, but not free.

ср, 17 мар. 2021 г. в 16:29, Kevin Chadwick <m8il...@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/lC9Z9VZXPdM/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/9be9cf18-7191-c81c-9b86-e15d1827f944%40gmail.com.

[Kevin Chadwick]

Thank You for answering

Regards, kc

[Ian Lance Taylor]

On Wed, Mar 17, 2021 at 4:28 AM Space A. <reexi...@gmail.com> wrote:
>
> Can you provide any proof that there was an open public discussion?

What kind of proof would you find to be acceptable? Can you give an
example of something that I could say that you would consider to be a
good answer to that question? Thanks.

Ian

[wilk]

On 17-03-2021, Ian Lance Taylor wrote:
> On Wed, Mar 17, 2021 at 4:28 AM Space A. <reexi...@gmail.com> wrote:
>>
>> Can you provide any proof that there was an open public discussion?
>
> What kind of proof would you find to be acceptable? Can you give an
> example of something that I could say that you would consider to be a
> good answer to that question? Thanks.

It is still possible to write a formal proposal "canceling generics" if
someone find now a good reason, right ? (at the time of modules i
believe it was).

Thanks for your patience

>
> Ian
>
>
>
>> ср, 17 мар. 2021 г. в 02:12, Ian Lance Taylor <ia...@golang.org>:
>>>
>>> On Tue, Mar 16, 2021 at 6:51 AM Space A. <reexi...@gmail.com> wrote:
>>> >
>>> > > (To be clear, your original claim was that there *was* no discussion - which is at least easy to address, because it's clearly not true. There was over three years of active discussion on this)
>>> >
>>> > No, and I can repeat, there was no (public) discussion on whether the idea of generics in Go should be completely dropped. It *was* always a "discussion" of how to improve and implement generics in a Go way, but not of generics themselves as something to be avoided by all means.
>>>
>>> I'm sorry, but that simply isn't the case. Many different people at
>>> many different times suggested that the idea of adding generics should
>>> be dropped. Those ideas were discussed, supported, opposed, and so
>>> forth. It's been a long discussion over many years.
>>>
>>> Ian
>

--
wilk

[Axel Wagner]

On Thu, Mar 18, 2021 at 12:06 PM wilk <wi...@flibuste.net> wrote:

It is still possible to write a formal proposal "canceling generics" if
someone find now a good reason, right ? (at the time of modules i
believe it was).

I believe it is. We can always change things in response to new information - we could, theoretically, even change decisions we made years ago.

However, it should be clear that the bar for what constitutes a "good reason" becomes higher over time. In particular, after the acceptance of the proposal, the minimum bar is that it really is new information. Because if the argument was already known, it was already considered and weighed as part of the decision.

As far as I can tell, the things mentioned in this thread (and other recent threads on this list) are not new. New information might be some technical difficulty in the implementation, or a corner case or fundamental problem we didn't know before. Evidence for overwhelming resistance to generics could also be new information. Though I'm not sure where it's supposed to come from - as mentioned a couple of times, it's hard to get representative polling information. But this was what ultimately killed the `try` error handling proposal, so it's not unthinkable.

 

Thanks for your patience

>
> Ian
>
>
>
>> ср, 17 мар. 2021 г. в 02:12, Ian Lance Taylor <ia...@golang.org>:
>>>
>>> On Tue, Mar 16, 2021 at 6:51 AM Space A. <reexi...@gmail.com> wrote:
>>> >
>>> > > (To be clear, your original claim was that there *was* no discussion - which is at least easy to address, because it's clearly not true. There was over three years of active discussion on this)
>>> >
>>> > No, and I can repeat, there was no (public) discussion on whether the idea of generics in Go should be completely dropped. It *was* always a "discussion" of how to improve and implement generics in a Go way, but not of generics themselves as something to be avoided by all means.
>>>
>>> I'm sorry, but that simply isn't the case.  Many different people at
>>> many different times suggested that the idea of adding generics should
>>> be dropped.  Those ideas were discussed, supported, opposed, and so
>>> forth.  It's been a long discussion over many years.
>>>
>>> Ian
>


--
wilk

--

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/s2vc5m%24sgd%241%40ciao.gmane.io.

[Space A.]

> What kind of proof would you find to be acceptable?  Can you give an
example of something that I could say that you would consider to be a
good answer to that question?  Thanks.

Ian, seriously. ANY evidence please, which you think "proves" that there was an open and public discussion on dropping generics from your daily agenda and focusing and spending time on more important things, such as first class Android support.

ср, 17 мар. 2021 г. в 22:44, Ian Lance Taylor <ia...@golang.org>:

[ma...@eliasnaur.com]

On Thursday, 18 March 2021 at 13:11:33 UTC+1 Space A. wrote:

> What kind of proof would you find to be acceptable?  Can you give an
example of something that I could say that you would consider to be a
good answer to that question?  Thanks.

Ian, seriously. ANY evidence please, which you think "proves" that there was an open and public discussion on dropping generics from your daily agenda and focusing and spending time on more important things, such as first class Android support.

Not only is this argument arrogant in judging importance on behalf of Ian (or the Go team), it is also invalid; all proposals, including generics, are judged on their merits, not in an importance competition with all other proposals.

Elias

[Axel Wagner]

ISTM that we already provided a bunch of evidence, which you are rejecting. so "any evidence" clearly is not good enough and you should be a bit more specific.

Just to name a few specific examples of evidence provided:

• The FAQ, as well as any interview of the question, have stated clearly that generics *may* be added, if a satisfying design is found. "May", not "will".

• The proposal process clearly mentions the option to reject a proposal.

• This push for including generics started simultaneously, using the same process, as both the "Error handling" and the "Error values" designs. "Error values" was accepted and "Error handling" was rejected as results of that process, so rejection was clearly a possible outcome.

• Since then, there have been numerous blog posts, threads on this mailing list, talks at conferences and appearances on podcasts by the Go team. All of them mention the possibility that generics might not happen. All threads (that I'm aware of) publicly discussing generics discuss the option not to include them at all at least once.

I really don't think it's too much to ask, what level of evidence you are actually looking for. I also strongly feel that the case made by us is stronger than the case made that there was no discussion about giving up on generics. The latter seems - as far as I can tell - mainly rely on a) interpreting statements by members of the Go team in ways incompatible with the actual words being said and b) speculating about the management process at Google - without any evidence to base this speculation on.

[Space A.]

That's exactly what I'm saying, topic of dropping generics was never raised, so landing of some version of generics was implied by the process. In fact just a start of that process implied that dropping them entirely was never a question. There was no public discussion with that regard, no poll or anything.

четверг, 18 марта 2021 г. в 15:42:44 UTC+3, axel.wa...@googlemail.com:

[Robert Engels]

One other point on this. Generics will be trivial for 95% of the people - they will only need to be able to read and write the instantiation statements of type safe collections. 

Most developers don’t write the generic implementations - these are provided by library authors. 

As I’ve said before, I would of taken a more go-like approach - generics seem too technical for most go developers - but in the end they will be a net benefit. 

On Mar 15, 2021, at 8:28 PM, Robert Engels <ren...@ix.netcom.com> wrote:



Very well said. 

On Mar 15, 2021, at 7:04 PM, Jeremy French <ibi...@gmail.com> wrote:

I was really trying not to weigh in here, mostly because it's a decision that has been decided, so there's not a lot of point in continuing the discussion, and yesterday it seemed like the thread would die, yet... it continues.

For context, I was against the generics proposal, primarily because it would make *my* life more complicated, while not providing *me* that much benefit.  I raised the concerns I had, especially in regards to the "if you don't like it, don't use it" arguments. I participated in a couple conversations on this mailing list.  In the end, I was fairly convinced that there were others in the community (and the community as a whole) who would benefit from the change far more than what it would cost me, and resigned myself to the change.

All of that is just to establish my bona fides.  If I were inclined to be biased on this topic, it would be against the Go team, not in their favor.  

And yet, I can say unequivocally that any suggestion that the Go team has railroaded this proposal through, or has ignored the concerns of its user base, is pure fiction.  Every single concern or question I've seen raised has been addressed respectfully and at face value - even, I would say - several concerns or complaints on this side of the argument that perhaps reasonably could have been scoffed at or dismissed as just stupid.  They have been respectful and attentive at every turn.  I don't necessarily agree or like the decision they made, but these character assassinations against them or implications that they are subject to corruption from their corporate parent have no supporting evidence that I've seen, including any presented in this thread.

It seems pretty clear that they are passionate about the health and longevity of the project, and are in the unenviable position of having to make a decision that is guaranteed to make some people angry no matter what they decide.  But in the end, it is their call to make, and they made it the best way they could think of to do so.  You can't ask any more than that.

On Monday, March 15, 2021 at 6:14:36 PM UTC-4 Ian Lance Taylor wrote:

On Mon, Mar 15, 2021 at 3:11 PM atd...@gmail.com <atd...@gmail.com> wrote:
>
> I am in favor of the proposal but I think that accounting for popularity votes is not a good measure of things.
> A lot of people are at various stages of their technical journey in computer science and engineering and there has to be a weight given to the more technical opinions that is not reflected in the github upvote/downvote system.
> At one point, everyone would have upvoted that the earth was flat.
>
> Just a note in passing :)

Yes. I am not saying that the proposal was adopted because it had
good support. I am arguing against the suggestion that the proposal
should not have been adopted because it had a lot of critics.

Ian


> On Monday, March 15, 2021 at 11:03:50 PM UTC+1 Ian Lance Taylor wrote:
>>
>> On Mon, Mar 15, 2021 at 5:08 AM Space A. <reexi...@gmail.com> wrote:
>> >
>> > > For example, the multiple proposals that flowed out of
>> > https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md.
>> > None of them have been adopted.
>> >
>> > I remember what was happening to "try" error handling proposal. It was withdrawn only because of active resistance by the community.
>> >
>> > And what's happened to a new "generics" proposal, it also got a lot of critics but was "accepted" in less than a month after formal publication on github. As Russ said "No change in consensus". What does it mean? Who are these people who can change the consensus? How was it measured? A few days after Russ locked it, so nobody can even say a word against it if they wanted. So it looks very much that company management learned from "try" proposal.

>>
>> The design draft was put up for discussion for months before it became
>> a formal proposal. It was not new.
>>

>> The formal proposal (https://golang.org/issue/43651) got 1784 thumbs
>> up and 123 thumbs down (and ten "confused"). Yes, there were critics.
>> But I think it is fair to say that the proposal has far more
>> supporters than critics.
>>

>> The "no change in consensus" comment refers to the discussion after
>> the proposal was moved to "likely accept" status:
>> https://github.com/golang/go/issues/43651#issuecomment-772744198.
>> After it was marked as "likely accept", there was no change to the
>> consensus that it should be accepted. (Note that the "likely accept"
>> comment got 60 thumbs up and 0 thumbs down (and one "confused").)
>>
>> None of this is anything like the "try" proposal
>> (https://golang.org/issue/32437), which had 318 thumbs up and 794
>> thumbs down (and 132 "confused").
>>
>> Ian

>
> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/932a39b7-be1b-4c15-b7c8-f99fce730b0en%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/6a690d7a-1f20-42d3-8528-94b80891d239n%40googlegroups.com.

[Axel Wagner]

I find your response disrespectful. You are completely ignoring (in the sense of "refusing to take notice of") what I wrote.

I don't think it is possible to have a productive conversation as long as you behave this way.

--
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/1624a7bf-1418-4a24-9e11-5ba8c76852b3n%40googlegroups.com.

[Space A.]

The same as you just did, completely ignored everything I said in this thread.

чт, 18 мар. 2021 г. в 16:25, Axel Wagner <axel.wa...@googlemail.com>:

[Space A.]

Since pro-generics ppl here are struggling to provide any evidence of existence of open and public discussion on the topic of dropping generics, I will do it myself.

Here is it: https://groups.google.com/g/golang-nuts/c/LEEuJPOg0oo/m/-EZp3YSeBQAJ

[Kent Sandvik]

I'm very dumb, but if you don't want to use generics or think they are bad for the language, why can't you just ignore them and not use them?

On Thu, Mar 18, 2021 at 7:07 AM Space A. <reexi...@gmail.com> wrote:

Since pro-generics ppl here are struggling to provide any evidence of existence of open and public discussion on the topic of dropping generics, I will do it myself.

Here is it: https://groups.google.com/g/golang-nuts/c/LEEuJPOg0oo/m/-EZp3YSeBQAJ

--
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/d8b96595-effe-4eed-898d-1c4e183189dbn%40googlegroups.com.

[Robert Engels]

I think the most plausible events are that various collections apis make it into the api as a “replacement” for the non type safe interface based ones. 

On Mar 18, 2021, at 11:20 AM, Kent Sandvik <san...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAHC_roGwVqqk9aiNv0h7Pa6XDDBWrr3HRBBMk9bHaZqjcrUG%3DQ%40mail.gmail.com.

[Axel Wagner]

I also think there is definitely credence to the idea that we read more code than we write (after all, a lot of Go's design is based on that idea too). So I definitely agree that most Go programmers will find it hard to avoid generics, even if they want. Usage of the language is very likely to change and generics are very likely to be used in a lot of Go code.

So, if we didn't think generics would make the language better, we shouldn't (and wouldn't) add them.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/0868C2C5-A4D5-4D38-B0B6-D1E955EAF7A4%40ix.netcom.com.

[Kent Sandvik]

So if I understand this correctly, you don't want to learn a new syntax in the language?

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHXZpBQSzYuck7h8b79q0D5eRYVpAgitoWuPNacJOT%3Dig%40mail.gmail.com.

[David Skinner]

I am very much pro generics, having used them with Go for many years.

I have only found them to be occasionally useful (10%), but on those occasions, it saves me time, improves reliability, and enhances the ability to maintain the code.

Having a background in MASM, TASM, Forth, Lisp, C++ leaves me comfortable with generics. Having one Java project where I was reading newbie use of generics was a traumatic experience that still gives me nightmares. So I totally respect those opposed to the generics.

New programmers do not need to learn about reflection, or generics, or goroutines to create modest programs that do extraordinary things. But as they advance by reading legacy code, and learning examples, these are things that they need to add to their toolbox. It does not matter to me if generics are added to the language or not as I have generics, but anyone reading my code must learn my version of generics implemented with +generate. So having a standardized version is great. And if it is not part of the language, you will still have to learn it and read and use it. I see no point at this time to not having a standard generics and have it fully implemented into the compiler, there is no significant long-term downside, only an improvement in productivity.

Some members of the Go team have used my version of generics and felt that it could be much better, and I agree. This change is not based on a whim, it is based on decades of experience and a decade of preparation.

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/lC9Z9VZXPdM/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/CAHC_roGwVqqk9aiNv0h7Pa6XDDBWrr3HRBBMk9bHaZqjcrUG%3DQ%40mail.gmail.com.

--

Respectfully submitted, David Lynn Skinner Secretary, Davsk Ltd Co IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email by mistake, please notify the sender immediately and do not disclose the contents to anyone or make copies thereof. Be like me, be Carbon free - don't print this and save a tree "Look deep into nature, and then you will understand everything better." - Albert Einstein. &nbsp Meet me on Zoom &nbsp Check out my blog

[Axel Wagner]

On Thu, Mar 18, 2021 at 5:59 PM Kent Sandvik <san...@gmail.com> wrote:

So if I understand this correctly, you don't want to learn a new syntax in the language?

That is not what I tried to say :) I'm leaning towards being in favor of adding generics.

I was trying to say that I think it's unavoidable that Go programmers will have to learn to read and use generic code.

I think it's very reasonable to acknowledge and consider the downsides of a change, while still being in favor of making it. That's kind of my point during this entire thread - that "we decided to add generics" doesn't mean we didn't hear or consider or even agree with the arguments against them. We just feel that the benefits outweigh them.

[Robert Engels]

I will point out again - there is a big difference between reading/writing generic “usage” code, and generic “implementation” code. The vast majority of developers will only need to do the former - and modern IDEs make this somewhat trivial. 

On Mar 18, 2021, at 12:57 PM, 'Axel Wagner' via golang-nuts <golan...@googlegroups.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfE8pz7m7oKuytYCs2NXks9W7rQhwSNXH3HEtyzYepiU9A%40mail.gmail.com.

[Ian Lance Taylor]

On Thu, Mar 18, 2021 at 5:11 AM Space A. <reexi...@gmail.com> wrote:
>
> > What kind of proof would you find to be acceptable? Can you give an
> example of something that I could say that you would consider to be a
> good answer to that question? Thanks.
>
> Ian, seriously. ANY evidence please, which you think "proves" that there was an open and public discussion on dropping generics from your daily agenda and focusing and spending time on more important things, such as first class Android support.

ANY evidence for a discussion about dropping generics?

https://groups.google.com/g/golang-nuts/c/LEEuJPOg0oo
https://groups.google.com/g/golang-nuts/c/bj6kMQBTqUY
https://groups.google.com/g/golang-nuts/c/uMBEmlejhzk/m/Uu1kYoDPBgAJ

Does that satisfy your request?

Ian

[Tyler Compton]

I think we all want to stick our noses in this thread. I'm going to stick my nose in it too :)

Space, I don't think you'll ever be happy as a result of this discussion, no matter what evidence or arguments others provide you. I think the fact is that you were burned by the outcome of the generics proposal. You didn't have the time to review the draft proposal and engage with the discussion early, and you disagree with the resulting outcome. That's unfortunate and I'm sorry it happened. I hope you don't feel that people are trying to convince you that you weren't burned. Nothing feels worse than having your concerns trivialized.

However, you have to understand that just because you were burned doesn't mean that those around you making these decisions are bad actors. There are probably small ways that this process could have been improved, but I don't think they would have changed the outcome. The reality is that after many iterations, the Go team created a proposal that a large enough number of Go users found beneficial for it to be accepted. I know you disagree with them, but our responsibility as members of this community is to exercise our right to disagree without resorting to attacks on character. I hope I've been able to address your concerns and disagree with you without making you feel I'm attacking your character.

To those who are still attempting to provide evidence that the generics proposal process was conducted in good faith, I think you've done everything you need to do and it's probably best to just let this one go.

On Thu, Mar 18, 2021 at 7:08 AM Space A. <reexi...@gmail.com> wrote:

Since pro-generics ppl here are struggling to provide any evidence of existence of open and public discussion on the topic of dropping generics, I will do it myself.

Here is it: https://groups.google.com/g/golang-nuts/c/LEEuJPOg0oo/m/-EZp3YSeBQAJ

--
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/d8b96595-effe-4eed-898d-1c4e183189dbn%40googlegroups.com.

[wilk]

On 18-03-2021, Tyler Compton wrote:

> I think we all want to stick our noses in this thread. I'm going to stick
> my nose in it too :)
>
> Space, I don't think you'll ever be happy as a result of this discussion,
> no matter what evidence or arguments others provide you. I think the fact
> is that you were burned by the outcome of the generics proposal. You didn't
> have the time to review the draft proposal and engage with the discussion
> early, and you disagree with the resulting outcome. That's unfortunate and
> I'm sorry it happened. I hope you don't feel that people are trying to
> convince you that you weren't burned. Nothing feels worse than having your
> concerns trivialized.
>
> However, you have to understand that just because you were burned doesn't
> mean that those around you making these decisions are bad actors. There are
> probably small ways that this process could have been improved, but I don't
> think they would have changed the outcome. The reality is that after many
> iterations, the Go team created a proposal that a large enough number of Go
> users found beneficial for it to be accepted. I know you disagree with
> them, but our responsibility as members of this community is to
> exercise our right to disagree without resorting to attacks on character. I
> hope I've been able to address your concerns and disagree with you without
> making you feel I'm attacking your character.
>
> To those who are still attempting to provide evidence that the generics
> proposal process was conducted in good faith, I think you've done
> everything you need to do and it's probably best to just let this one go.

+1

--
wilk

[Space A.]

Two of them are recent discussions which I was part of, and yet another is also a recent post, not really a discussion since there are 2 messages in thread, just an opinion.

So yea, thank you for proving my words.

чт, 18 мар. 2021 г. в 22:00, Ian Lance Taylor <ia...@golang.org>:

[Space A.]

Ok so this is a nice post. What you are trying to do with it is to make an impression that there is only I in the whole Universe who was unhappy with that proposal.

It's not true. Open the issue and read down below comments by other people. Some others who might also wanted to give their feedback can't do this because it was locked and there is no intent to listen to them.

> Go team created a proposal that a large enough number of Go users found beneficial for it to be accepted

1. Since some time I don't know what "Go team" is. As Google put a trademark on Go, and its own label on golang.org website, so they obviously wanted that everyone was aware of who stands behind the project, it would be correct to say "a group of Google employees".

2. Sure, Ian has revealed how that "consensus" was measured. By counting "thumbs up", "thumbs down" and "confused" emojis. So Go is not driven by polls, it's driven by emojis.

 

чт, 18 мар. 2021 г. в 23:22, Tyler Compton <xav...@gmail.com>: