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+unsubscr...@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+unsubscr...@googlegroups.com";>golang-= > nuts+unsubscr...@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/rs1gpv%24144l%241%40ciao.gmane.io.
