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