Re: [go-nuts] No generic, part -2

[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 :

> 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.  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+unsubscr...@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
>> <https://groups.google.com/d/msgid/golang-nuts/d8b96595-effe-4eed-898d-1c4e183189dbn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

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

Re: [go-nuts] No generic, part -2

[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 :

> On Thu, Mar 18, 2021 at 5:11 AM 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.
>
> 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
>

-- 
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/CADKwOTd15zPr2EpPRfij6VOFOe%3DOAKenVkaJXtfuPCgqMh3GWw%40mail.gmail.com.

Re: [go-nuts] now that the election is over can we please remove the political ad for golang.org

[Space A.]

Sorry but if you don't want to be targeted, resign from your manager's
position. Less responsibility, less spotlight, and still good compensation
package from Google.

чт, 18 мар. 2021 г. в 20:45, Andrew Bonventre :

> This conversation has not been adhering to Go’s values
>  of being respectful and charitable with each
> other. I’d like to request it come to an end.
>
> Additionally, please do not make assumptions about specific members of the
> community and their role in things. I was “in charge” of the Go websites
> when this banner was launched and I stand by any decision those on the core
> team make on this. Targeting Russ is inappropriate and unfounded.
>
> Thanks,
> Andy
> On Thursday, March 18, 2021 at 1:11:09 PM UTC-4 Thomas Bushnell, BSG wrote:
>
>> On Wed, Mar 17, 2021 at 8:33 AM mortdeus  wrote:
>>
>>> Are you absolutely SURE you want to keep up the "your not welcome here"
>>> sign to people who literally find the message to be dangerous to the very
>>> people they claim to want to protect. Do we really want to encourage an
>>> opensource culture, where people will literally fork a language just
>>> because they don't like the political grandstanding going on because the
>>> people who are supposed to be the smartest people in the world are stupid
>>> enough to abandon liberal principles for wokeism?
>>>
>>
>> I cannot speak for the Go authors, and I certainly cannot speak for
>> Google, but I can say for my part that I want a very clear and very bright
>> sign that racists are not welcome here, no matter how brilliantly they can
>> write computer programs.
>>
>> Thomas
>>
> --
> 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/DHO4ZZkR8JA/unsubscribe.
> To unsubscribe from this group and all its topics, 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/31872752-2c7e-4a1d-b175-7cc749c393b8n%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CADKwOTcmXiVFjP_zRRfY-nTTsisr2KN7MsObZpJ5jJ67LgJCjA%40mail.gmail.com.

Re: [go-nuts] now that the election is over can we please remove the political ad for golang.org

[Space A.]

> that racists are not welcome here
You probably mean white racists?
But black are welcomed.

I also very like this cite:

“It should be noted that no ethically -trained software engineer would ever
consent to write a DestroyBaghdad procedure. Basic professional ethics
would instead require him to write a DestroyCity procedure, to which
Baghdad could be given as a parameter.”

― Nathaniel S. Borenstein



чт, 18 мар. 2021 г. в 20:11, 'Thomas Bushnell BSG' via golang-nuts <
golang-nuts@googlegroups.com>:

> On Wed, Mar 17, 2021 at 8:33 AM mortdeus  wrote:
>
>> Are you absolutely SURE you want to keep up the "your not welcome here"
>> sign to people who literally find the message to be dangerous to the very
>> people they claim to want to protect. Do we really want to encourage an
>> opensource culture, where people will literally fork a language just
>> because they don't like the political grandstanding going on because the
>> people who are supposed to be the smartest people in the world are stupid
>> enough to abandon liberal principles for wokeism?
>>
>
> I cannot speak for the Go authors, and I certainly cannot speak for
> Google, but I can say for my part that I want a very clear and very bright
> sign that racists are not welcome here, no matter how brilliantly they can
> write computer programs.
>
> Thomas
>
> --
> 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/DHO4ZZkR8JA/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CA%2BYjuxskL_ypkm7rthr1374dXBOFQDoG3Y2e3pdivz748sK2iw%40mail.gmail.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CADKwOTerPRMDJ7wV7-HUM5Z%3D7c8%2B86ywX4NvFcrxjYd2ZhyoJw%40mail.gmail.com.

Re: [go-nuts] No generic, part -2

[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



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

Re: [go-nuts] No generic, part -2

[Space A.]

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

чт, 18 мар. 2021 г. в 16:25, 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.
>
> On Thu, Mar 18, 2021 at 1:48 PM Space A.  wrote:
>
>> 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:
>>
>>> 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
>>> <https://github.com/golang/proposal#the-proposal-process> clearly
>>> mentions the option to reject a proposal.
>>> • This push for including generics started simultaneously, using the
>>> same process <https://blog.golang.org/go2draft>, 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.
>>>
>>> On Thu, Mar 18, 2021 at 1:11 PM 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.
>>>>
>>>> ср, 17 мар. 2021 г. в 22:44, Ian Lance Taylor :
>>>>
>>>>> On Wed, Mar 17, 2021 at 4:28 AM Space A.  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
>>>>>
>>>>>
>>>>> --
>> 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/1624a7bf-1418-4a24-9e11-5ba8c76852b3n%40googlegroups.com
>> <https://groups.google.com/d/msgid/golang-nuts/1624a7bf-1418-4a24-9e11-5ba8c76852b3n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/CADKwOTdE5JkAqrq1q%3DMerb%2BXGjZFCxYN-KZrb5mgctTGCbL7YQ%40mail.gmail.com.

Re: [go-nuts] No generic, part -2

[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: 

> 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 
> <https://github.com/golang/proposal#the-proposal-process> clearly 
> mentions the option to reject a proposal.
> • This push for including generics started simultaneously, using the same 
> process <https://blog.golang.org/go2draft>, 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.
>
> On Thu, Mar 18, 2021 at 1:11 PM 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.
>>
>> ср, 17 мар. 2021 г. в 22:44, Ian Lance Taylor :
>>
>>> On Wed, Mar 17, 2021 at 4:28 AM Space A.  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
>>>
>>>
>>>

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

Re: [go-nuts] Re: now that the election is over can we please remove the political ad for golang.org

[Space A.]

Btw, when this started (see original thread) I compared some main pages of 
websites of popular languages. And you know what? I didn't find stupid 
banner on Java or Rust websites, and on many others. Maybe they were smart 
enough to show it only to US visitors, idk. Anyways, Russ Cox obviously 
thinks that there is no other world, so... 

" To people who object to the banner as too focused on the United States: 
Google and Go both started here, nearly all of the Go team is here, a 
substantial number of Go community members live here, and many others 
travel here for conferences or other reasons. The situation here affects 
gophers worldwide. "

So if you live outside of US, and contributed to the language or ecosystem 
you can literally go to hell, as according to him, only US-related activity 
counts and matters. 

Actually "situation there" does not affect me because I use ABP, but funny 
thing is there is chance that Go will become first programming language 
ever whose website will end up in spam filters.


среда, 17 марта 2021 г. в 21:47:33 UTC+3, Rusco: 

> afaik George Soros is behind the BLM Campaign, this alone justifies 
> removing the banner. From now on the Golang Community should be inclusive 
> and tolerate all political opinions. Seems to be harder than writing speedy 
> go code ... 
>
> On Wednesday, 17 March 2021 at 17:59:52 UTC mortdeus wrote:
>
>> "Ian, This individual is either trolling us or suffering some sort of 
>> psychological crisis that warrants intervention by a mental health 
>> professional."
>>
>> Somewhere in the middle, but mostly drunk and extremely aggravated.
>>
>> If what I am saying is annoying you to the point that you want to ban me. 
>> Then just understand that unlike you, I don't get the option to magically 
>> "ban" away the seriously offensive to conservative political ads.
>>
>> Just because you don't understand why BLM "triggers" us. (to use your 
>> terminology) is because you weren't on the other side being persecuted for 
>> your beliefs during this past election. 
>>
>> What's the goal here, to be inclusive to everybody regardless of sex, 
>> race, religion. Or to literally say we draw a line at religion. Because 
>> that is what a political ideology is. Dogma you subscribe to so faithfully 
>> that you convinced you are the only one that is saved and the rest of the 
>> world be damned. 
>>
>> Ban me, because honestly you'd probably be doing me a favor. But like I 
>> mentioned earlier, this is the one issue that is actually heartbreaking to 
>> me. The idea that in order to be a Good Gopher you best vote for Joe Biden.
>>
>> idk im done. ive said all that needed to be said. do what you will, but 
>> just understand that nobody here will have any excuses if it turns out that 
>> the cranks like myself were right in shouting at the top of their lungs 
>> "HEY YOU REAY DONT WANT TO FOLLOW THE RABBIT DOWN THAT HOLE 
>> UNLESS YOU ARE ALICE"
>>
>> You aren't Alice and this story wasn't written with you in mind.
>>
>>
>> On Wednesday, March 17, 2021 at 12:40:19 PM UTC-5 Kurtis Rader wrote:
>>
>>> Ian, This individual is either trolling us or suffering some sort of 
>>> psychological crisis that warrants intervention by a mental health 
>>> professional. Either way I think we've all had quite enough of their rants 
>>> and their behavior warrants banning from this mailing list.
>>>
>>> On Wed, Mar 17, 2021 at 10:33 AM mortdeus  wrote:
>>>
 There is a reason why Steve Jobs spent all the day, yelling at you 
 stubborn #&@#s for not getting why Bob Dylan is an essential component to 
 why Apple is now the most valuable company in the world. 

 If what I am saying sounds crazy, just know you thought my ideas were 
 the dopest ideas in SV when he crammed everything I just said ^ into 
 "Think 
 Different" and had the cult of personality thing going for him, so you 
 would all just listen and do. 

 On Wednesday, March 17, 2021 at 12:28:28 PM UTC-5 mortdeus wrote:

> I literally don't want the banner because I don't like the way it 
> looks. It's really like an ocd thing for me. And you all need to 
> understand, that is extremely important. Way more important than your 
> political concerns. Because like I said, a tool like this is honestly the 
> only effective way to implement the change you all claim to be advocates 
> for. That is why it needs to remain unmolested. 
>
> On Wednesday, March 17, 2021 at 12:26:19 PM UTC-5 mortdeus wrote:
>
>> No Go is literally a 1000x bigger achievement than the Mona Lisa, 
>> because somehow we managed to get a bunch of people to come together and 
>> somehow create a miracle of engineering. 
>>
>> In a perfect world, where the market also adopts the most efficient 
>> technological solutions.
>>
>> Plan 9 should have been the operating system that ruled the Earth and 
>> became essentially 

Re: [go-nuts] No generic, part -2

[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 :

> On Wed, Mar 17, 2021 at 4:28 AM Space A.  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
>
>
>

-- 
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/CADKwOTe94%2BPj6pQ%3DnW3FLez-aLMUN9%3DjRJBUnXCyferTRZeYwg%40mail.gmail.com.

Re: [go-nuts] Healthy tinygo Was: No generic, part -2

[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 :

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

-- 
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/CADKwOTfnGnDw8%2BU9gGyWz_oZj0CP9wjzhfjbOYta%3DDpoDAAMcQ%40mail.gmail.com.

Re: [go-nuts] No generic, part -2

[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 :

> Dnia 2021-03-17, o godz. 14:27:51
> "Space A."  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
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/20210317125511.46a0698d%40xmint
> .
>

-- 
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/CADKwOTdu%3DsEFYnNaPK1CcqdkpAoszNwF%2BEQvO%2B6U6pDgSJHiOg%40mail.gmail.com.

Re: [go-nuts] Healthy tinygo Was: No generic, part -2

[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 :

> >> 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.
> >
>
> 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?
>
> --
> 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+unsubscr...@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
> .
>

-- 
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/CADKwOTdaFSSt2xVG_q1SZmx%2BN70D6zuuYg8csGDnd76mWfwzBQ%40mail.gmail.com.

Re: [go-nuts] No generic, part -2

[Space A.]

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



ср, 17 мар. 2021 г. в 02:12, Ian Lance Taylor :

> On Tue, Mar 16, 2021 at 6:51 AM Space A.  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
>

-- 
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/CADKwOTea5cyYwcEQygc_LT6AAJAez2jgVQsuS%2Bm72KQCnKcLEg%40mail.gmail.com.

Re: [go-nuts] No generic, part -2

[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 :

> On Tue, Mar 16, 2021 at 4:00 AM Space A.  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
>

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

Re: [go-nuts] No generic, part -2

[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 :

> 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?
>
> On Tuesday, March 16, 2021 at 8:24:27 PM UTC+8 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.
>>
>> > 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 :
>>
>>> On Tue, Mar 16, 2021 at 12:00 PM Space A.  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
>>> <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.
>>>
>>> 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
>>> t

Re: [go-nuts] Re: No generic, part -2

[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 :

> 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
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/s2qag8%24i2a%241%40ciao.gmane.io
> .
>

-- 
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/CADKwOTf5%3DTy5e1LDDyk0iG_8TSEB_rp5sQFSNKhdnnuPwVrr2g%40mail.gmail.com.

Re: [go-nuts] No generic, part -2

[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 :

> On Tue, Mar 16, 2021 at 1:24 PM Space A.  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.
>
>
>>
>>
>>
>>
>> вт, 16 мар. 2021 г. в 15:05, Axel Wagner :
>>
>>> On Tue, Mar 16, 2021 at 12:00 PM Space A.  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
>>> <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.
>>>
>>> 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 

Re: [go-nuts] No generic, part -2

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

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

> On Tue, Mar 16, 2021 at 12:00 PM Space A.  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
> <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.
>
> 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.
>
>
>>
>>
>>
>>
>> вт, 16 мар. 2021 г. в 01:03, Ian Lance Taylor :
>>
>>> On Mon, Mar 15, 2021 at 5:08 AM Space A.  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 the

Re: [go-nuts] No generic, part -2

[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 :

> On Mon, Mar 15, 2021 at 5:08 AM Space A.  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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CADKwOTc%2BmjiJOia%3DGt%3D63xAdPmbRSo5RE9XJaNxcp2g38bXoxA%40mail.gmail.com.

Re: [go-nuts] No generic, part -2

[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 :

> 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.
>
> On Saturday, March 13, 2021 at 11:35:23 AM UTC-6 axel.wa...@googlemail.com
> wrote:
>
>> On Sat, Mar 13, 2021 at 6:24 PM Space A.  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.
>>
>>
>>
>>> сб, 13 мар. 2021 г. в 19:39, Axel Wagner :
>>>
>>>> On Sat, Mar 13, 2021 at 4:59 PM Space A.  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 solutio

Re: [go-nuts] No generic, part -2

[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 :

> On Sat, Mar 13, 2021 at 7:59 AM Space A.  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
>

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

Re: [go-nuts] No generic, part -2

[Space A.]

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

пн, 15 мар. 2021 г. в 05:30, Ian Lance Taylor :

> On Sat, Mar 13, 2021 at 9:25 AM Space A.  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
>

-- 
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/CADKwOTcwcsmfWvKio-%2BQKZUN8bsK157aADKm0qcukbh5WNVh5A%40mail.gmail.com.

Re: [go-nuts] No generic, part -2

[Space A.]

> Here is a recent example I was involved in
<https://github.com/golang/go/issues/43223#issuecomment-772733473>. 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 :

> On Sat, Mar 13, 2021 at 4:59 PM Space A.  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
> <https://github.com/golang/go/issues/43223#issuecomment-772733473>. 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) 

Re: [go-nuts] No generic, part -2

[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 :

> On Sat, Mar 13, 2021 at 4:19 PM Space A.  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
> <https://github.com/golang/go/blob/dd64f86e0874804d0ec5b7138dafc28b51f61c12/doc/go_lang_faq.html#L170>
>  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
> <https://github.com/golang/go/issues/43651#issuecomment-776944155>. 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.
>
>
>>
>>
>>
>> сб, 13 мар. 2021 г. в 17:31, 'Axel Wagner' via golang-nuts <
>> golang-nuts@googlegroups.com>:
>>
>>> 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.
>>>
>>> On Sat, Mar 13, 2021 at 3:19 PM Space A.  wrote:
>>>
>>>> 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 prog

Re: [go-nuts] No generic, part -2

[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 <
golang-nuts@googlegroups.com>:

> 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.
>
> On Sat, Mar 13, 2021 at 3:19 PM Space A.  wrote:
>
>> 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 :
>>
>>> (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
>>>
>>> On 13.03.21 12:34, Space A. wrote:
>>> > 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:
>>> >
>>> > 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.
>>> >
>>> > On Saturday, March 13, 2021 at 7:15:06 AM UTC+3 Ian Lance Taylor
>>> wrote:
>>> >
>>> > On Fri, Mar 12, 2021 at 7:31 AM alex-coder >> >
>>> > wrote:
>>> >  >
>>> >  > Hello again,
>>> >  > I apologize for being so intrusive.
>>> >  > Wher

Re: [go-nuts] No generic, part -2

[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 :

> 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.
>
> Le sam. 13 mars 2021 à 12:34, Space A.  a écrit :
>
>> 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:
>>
>>> 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.
>>>
>>> On Saturday, March 13, 2021 at 7:15:06 AM UTC+3 Ian Lance Taylor wrote:
>>>
>>>> On Fri, Mar 12, 2021 at 7:31 AM 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 ?
>>>>
>>>> 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
>>>>
>>> --
>> 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/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_source=footer>
>> .
>>
>

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

Re: [go-nuts] No generic, part -2

[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 :

> (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
>
> On 13.03.21 12:34, Space A. wrote:
> > 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:
> >
> > 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.
> >
> > On Saturday, March 13, 2021 at 7:15:06 AM UTC+3 Ian Lance Taylor
> wrote:
> >
> > On Fri, Mar 12, 2021 at 7:31 AM 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 ?
> >
> > 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-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+unsubscr...@googlegroups.com
> > <mailto:golang-nuts+unsubscr...@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_source=footer
> >.
>
> --
> You

Re: [go-nuts] No generic, part -2

[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: 

> 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.
>
> On Saturday, March 13, 2021 at 7:15:06 AM UTC+3 Ian Lance Taylor wrote:
>
>> On Fri, Mar 12, 2021 at 7:31 AM 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 ?
>>
>> 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
>>
>

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

Re: [go-nuts] The Generics Proposal has been accepted!

[Space A.]

> But it doesn't give you the right to insult the community this way.
Not a community, but a particular (shit) show.



ср, 17 февр. 2021 г. в 15:22, Mohamed Yousif :

> I really don't know why you have been constantly negative.
>
> It seems like you genuinely care about the language and what it brought to
> you, and worried of what might the future bring to us. That's
> understandable. But it doesn't give you the right to insult the community
> this way.
>
>
> On Wed, 17 Feb 2021, 1:50 pm Space A.,  wrote:
>
>> Shit show.
>>
>> вторник, 16 февраля 2021 г. в 21:52:43 UTC+3, skinne...@gmail.com:
>>
>>> I have been so very much looking forward to Go 2.0 and generics. Getting
>>> it in 1.18 is the icing on the cake. I seriously did not think you could do
>>> it considering that everyone was pulling you in different directions. Well
>>> Done! Defining the job is 90% of the project. The coding and testing before
>>> you ship will likely be the other 90%. I am looking forward to testing the
>>> new product! Thanks.
>>>
>>> On Friday, February 12, 2021 at 10:01:27 AM UTC-6 Amnon wrote:
>>>
>>>> Thanks, Ian, for the correction, and for all the hard work...
>>>> All much appreciated!
>>>>
>>>> On Friday, 12 February 2021 at 15:49:57 UTC Ian Lance Taylor wrote:
>>>>
>>>>> On Fri, Feb 12, 2021 at 7:39 AM Amnon  wrote:
>>>>> >
>>>>> > And should be out in 1.17 (this Autumn).
>>>>> >
>>>>> > Congratulations to all those who made it happen,
>>>>> > and to the Go team for making sure that the design was right before
>>>>> it
>>>>> > was accepted.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> But, a clarification: we are targeting the 1.18 release for generics,
>>>>> not the 1.17 release. There is a lot of work to do.
>>>>>
>>>>> 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+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/296b74fe-2dab-4c28-b725-76ec8905a24en%40googlegroups.com
>> <https://groups.google.com/d/msgid/golang-nuts/296b74fe-2dab-4c28-b725-76ec8905a24en%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

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

Re: [go-nuts] The Generics Proposal has been accepted!

[Space A.]

Shit show.

вторник, 16 февраля 2021 г. в 21:52:43 UTC+3, skinne...@gmail.com: 

> I have been so very much looking forward to Go 2.0 and generics. Getting 
> it in 1.18 is the icing on the cake. I seriously did not think you could do 
> it considering that everyone was pulling you in different directions. Well 
> Done! Defining the job is 90% of the project. The coding and testing before 
> you ship will likely be the other 90%. I am looking forward to testing the 
> new product! Thanks.
>
> On Friday, February 12, 2021 at 10:01:27 AM UTC-6 Amnon wrote:
>
>> Thanks, Ian, for the correction, and for all the hard work...
>> All much appreciated! 
>>
>> On Friday, 12 February 2021 at 15:49:57 UTC Ian Lance Taylor wrote:
>>
>>> On Fri, Feb 12, 2021 at 7:39 AM Amnon  wrote: 
>>> > 
>>> > And should be out in 1.17 (this Autumn). 
>>> > 
>>> > Congratulations to all those who made it happen, 
>>> > and to the Go team for making sure that the design was right before it 
>>> > was accepted. 
>>>
>>> Thanks! 
>>>
>>> But, a clarification: we are targeting the 1.18 release for generics, 
>>> not the 1.17 release. There is a lot of work to do. 
>>>
>>> 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/296b74fe-2dab-4c28-b725-76ec8905a24en%40googlegroups.com.

[go-nuts] Re: How to get VSCode to use different Go env vars for different directories in the same repo?

[Space A.]

Hi,

the solution would be:

1. Protect WASM source files with build flags so that when you open a 
"backend" main sources, IDE won't complain about "syscall/js", like this:
// +build js,wasm
2. Open `wasm` directory in second instance of VS Code for which you would 
set GOOS and GOARCH for a workspace. When editing settings in json, click 
on "workspace" tab and VS Code will create .vscode/settings.json in `wasm` 
directory. Put something like:
{
"go.toolsEnvVars": {
"GOOS": "js",
"GOARCH": "wasm",
}
}
in there.
3. In future, work in two instances of VS Code, even though if logically 
it's a different parts of same project and could be under the same Go 
module. All IDE features will work fluently. I haven't seen any problems 
with this approach so far.


суббота, 13 февраля 2021 г. в 23:42:06 UTC+3, michael...@gmail.com: 

> *(Sorry for posting what is mostly a VSCode question. I've asked it on 
> StackOverflow without getting any responses.  Am reposting here in the hope 
> that some has already run into this problem and figured out how to deal 
> with it.)*
>
> I have a Go project that builds a WebAssembly (WASM)  app and a backend 
> server for it. Both pieces build and run without errors. VSCode, however, 
> produces an annoying linter error in the WASM app.
>
> ```
> could not import syscall/js (no required module provides package 
> "syscall/js")
> ```
>
> The problem, as I currently understand it, is that VSCode doesn't infer 
> from the build tags that it should invoke `gopls` with `env GOOS=js 
> GOARCH=wasm` and that one solution is to set these tags as workspace Go 
> environment vars.
>
> The app design, however, relies on providing a common internal package to 
> both the wasm and the server code so that each side sees some struct 
> definitions that simplify the interface between them. To that end, the repo 
> is organized (simplified view) as follows:
>
> ```
> cmd
> ├── internal
> │   └── common
> │   ├── common.go
> │   └── common_test.go
> ├── server
> │   └── main.go
> └── wasm
> └── main.go
> ```
>
> How can I configure VSCode to use `env GOOS=js GOARCH=wasm` when linting 
> the wasm directory and not for other directories? 
>
>
>
>
>
>

-- 
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/ed6caf0c-64ec-454d-8926-dc9cbb98d8a5n%40googlegroups.com.

Re: [go-nuts] Generics, please go away!

[Space A.]

I didn't say you can't write Java without using a framework.
I didn't say using a framework has anything to do with OOP.
I didn't say there are no or just a few "frameworks" (whatever you mean) in
Go.
I didn't say you can't create framework without using inheritance.


сб, 2 янв. 2021 г. в 02:35, robert engels :

> I really hope my negative perception of your attitude stems from a
> language barrier. To clarify, I was trying to state that you can write Java
> without using a framework, just as you can write Go using a framework.
> Using a framework has nothing to do with OOP. Even the term framework is
> misleading - there are many large “libraries” in C that I would consider a
> framework.
>
> On Jan 1, 2021, at 5:05 PM, Space A.  wrote:
>
> You keep replying with random sentences no matter what I say, just
> combining known words in random phrases. Okay, but please put me out of
> your list, cause I have better games to play.
>
>
> сб, 2 янв. 2021 г. в 00:50, robert engels :
>
>> Those concerns are unrelated. There are plenty of frameworks in Go as
>> well. You can create frameworks without using inheritance.
>>
>> On Jan 1, 2021, at 2:51 PM, Space A.  wrote:
>>
>> Composition is just a principle, which can be implemented on different
>> layers by different ways. I'd say in Java you will be forced not only to
>> follow OOP (with inheritance and all of that ofc) even if you don't need
>> it, you will end up writing in some framework and that framework will
>> become your language, rather than vanilla Java, unless you're doing simple
>> examples for students. First question Go newcomers ask on forums which
>> framework I should use for my application.
>>
>>
>>
>> пт, 1 янв. 2021 г. в 23:27, robert engels :
>>
>>> You can write Java (or any other OOP with inheritance) using composition
>>> rather than inheritance. Much of the Java stdlib uses both. It can be
>>> argued that most usages of anonymous inner classes are composition rather
>>> than inheritance.
>>>
>>> On Jan 1, 2021, at 1:59 PM, Space A.  wrote:
>>>
>>> > Wait, I think I get it. Are you making a distinction between object
>>> oriented /languages/ and object oriented /programs/ (which may or may not
>>> be written in an object oriented language)?
>>> You are absolutely correct, my friend, so you see, OOP is just a
>>> paradigm in software development. Program can be entirely OOP, or
>>> partially, such as module, or library. And you have tools such as
>>> programming languages. When these languages provide you with instruments
>>> for building your OOP program *out of the box*, being a first-class
>>> citizens, you could call that language OOP. Key feature of major OOP
>>> languages is inheritance and all supporting stuff. But you can use non-OOP
>>> language such as C, just that you will need to add some moving parts
>>> yourself instead of using what's given by language.
>>>
>>> Same with CSP. Go is often called a CSP language, or language with CSP
>>> capabilities, because it has all needed features, such as goroutines and
>>> channels out of the box as first class objects. But this doesn't mean you
>>> cannot write CSP program in any other language, you can, but you will
>>> sometimes have to invent a wheel.
>>>
>>>
>>> > For example, from my interpretation of your definition, Java and C++
>>> would be considered object oriented languages, because they favor class
>>> inheritance over composition. But a language like Scheme or JavaScript
>>> would not be considered an object oriented language because they do not
>>> have traditional class inheritance.
>>> Exactly. Thank you for giving me hope that at the end at least some of
>>> us living on the same planet.
>>>
>>>
>>> пт, 1 янв. 2021 г. в 19:07, Beka Westberg :
>>>
>>>> > First of all I feel it's more rhetoric, it's same as "Less is
>>>> exponentially more", and "[Go] ... Arguably more object oriented than say
>>>> Java or C++ ". I believe if you think logically "less" could not be "more",
>>>> right, and you wouldn't insist on that? Same goes to the statement that Go
>>>> is more object oriented. What I think he meant was "Go has even better
>>>> compatibilities even for OOP because of composition" which also in line
>>>> with what I said that you can use ANY language to write OOP program.
>>>>
>>>> Wait, I think I get it. Ar

Re: [go-nuts] Generics, please go away!

[Space A.]

You keep replying with random sentences no matter what I say, just
combining known words in random phrases. Okay, but please put me out of
your list, cause I have better games to play.


сб, 2 янв. 2021 г. в 00:50, robert engels :

> Those concerns are unrelated. There are plenty of frameworks in Go as
> well. You can create frameworks without using inheritance.
>
> On Jan 1, 2021, at 2:51 PM, Space A.  wrote:
>
> Composition is just a principle, which can be implemented on different
> layers by different ways. I'd say in Java you will be forced not only to
> follow OOP (with inheritance and all of that ofc) even if you don't need
> it, you will end up writing in some framework and that framework will
> become your language, rather than vanilla Java, unless you're doing simple
> examples for students. First question Go newcomers ask on forums which
> framework I should use for my application.
>
>
>
> пт, 1 янв. 2021 г. в 23:27, robert engels :
>
>> You can write Java (or any other OOP with inheritance) using composition
>> rather than inheritance. Much of the Java stdlib uses both. It can be
>> argued that most usages of anonymous inner classes are composition rather
>> than inheritance.
>>
>> On Jan 1, 2021, at 1:59 PM, Space A.  wrote:
>>
>> > Wait, I think I get it. Are you making a distinction between object
>> oriented /languages/ and object oriented /programs/ (which may or may not
>> be written in an object oriented language)?
>> You are absolutely correct, my friend, so you see, OOP is just a paradigm
>> in software development. Program can be entirely OOP, or partially, such as
>> module, or library. And you have tools such as programming languages. When
>> these languages provide you with instruments for building your OOP program
>> *out of the box*, being a first-class citizens, you could call that
>> language OOP. Key feature of major OOP languages is inheritance and all
>> supporting stuff. But you can use non-OOP language such as C, just that you
>> will need to add some moving parts yourself instead of using what's given
>> by language.
>>
>> Same with CSP. Go is often called a CSP language, or language with CSP
>> capabilities, because it has all needed features, such as goroutines and
>> channels out of the box as first class objects. But this doesn't mean you
>> cannot write CSP program in any other language, you can, but you will
>> sometimes have to invent a wheel.
>>
>>
>> > For example, from my interpretation of your definition, Java and C++
>> would be considered object oriented languages, because they favor class
>> inheritance over composition. But a language like Scheme or JavaScript
>> would not be considered an object oriented language because they do not
>> have traditional class inheritance.
>> Exactly. Thank you for giving me hope that at the end at least some of us
>> living on the same planet.
>>
>>
>> пт, 1 янв. 2021 г. в 19:07, Beka Westberg :
>>
>>> > First of all I feel it's more rhetoric, it's same as "Less is
>>> exponentially more", and "[Go] ... Arguably more object oriented than say
>>> Java or C++ ". I believe if you think logically "less" could not be "more",
>>> right, and you wouldn't insist on that? Same goes to the statement that Go
>>> is more object oriented. What I think he meant was "Go has even better
>>> compatibilities even for OOP because of composition" which also in line
>>> with what I said that you can use ANY language to write OOP program.
>>>
>>> Wait, I think I get it. Are you making a distinction between object
>>> oriented /languages/ and object oriented /programs/ (which may or may not
>>> be written in an object oriented language)?
>>>
>>> For example, from my interpretation of your definition, Java and C++
>>> would be considered object oriented languages, because they favor class
>>> inheritance over composition. But a language like Scheme or JavaScript
>>> would not be considered an object oriented language because they do not
>>> have traditional class inheritance.
>>>
>>> However, it seems like you are saying that you can write an object
>>> oriented /program/ in any of the above languages? Each of the above
>>> languages allows you to create "things" that have internal mutable state,
>>> and can receive messages, which seems like a pretty good definition of an
>>> object :D Hence, object oriented programming is possible.
>>>
>>> I don't really have an opinion on this. 

Re: [go-nuts] Generics, please go away!

[Space A.]

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



пт, 1 янв. 2021 г. в 23:27, robert engels :

> You can write Java (or any other OOP with inheritance) using composition
> rather than inheritance. Much of the Java stdlib uses both. It can be
> argued that most usages of anonymous inner classes are composition rather
> than inheritance.
>
> On Jan 1, 2021, at 1:59 PM, Space A.  wrote:
>
> > Wait, I think I get it. Are you making a distinction between object
> oriented /languages/ and object oriented /programs/ (which may or may not
> be written in an object oriented language)?
> You are absolutely correct, my friend, so you see, OOP is just a paradigm
> in software development. Program can be entirely OOP, or partially, such as
> module, or library. And you have tools such as programming languages. When
> these languages provide you with instruments for building your OOP program
> *out of the box*, being a first-class citizens, you could call that
> language OOP. Key feature of major OOP languages is inheritance and all
> supporting stuff. But you can use non-OOP language such as C, just that you
> will need to add some moving parts yourself instead of using what's given
> by language.
>
> Same with CSP. Go is often called a CSP language, or language with CSP
> capabilities, because it has all needed features, such as goroutines and
> channels out of the box as first class objects. But this doesn't mean you
> cannot write CSP program in any other language, you can, but you will
> sometimes have to invent a wheel.
>
>
> > For example, from my interpretation of your definition, Java and C++
> would be considered object oriented languages, because they favor class
> inheritance over composition. But a language like Scheme or JavaScript
> would not be considered an object oriented language because they do not
> have traditional class inheritance.
> Exactly. Thank you for giving me hope that at the end at least some of us
> living on the same planet.
>
>
> пт, 1 янв. 2021 г. в 19:07, Beka Westberg :
>
>> > First of all I feel it's more rhetoric, it's same as "Less is
>> exponentially more", and "[Go] ... Arguably more object oriented than say
>> Java or C++ ". I believe if you think logically "less" could not be "more",
>> right, and you wouldn't insist on that? Same goes to the statement that Go
>> is more object oriented. What I think he meant was "Go has even better
>> compatibilities even for OOP because of composition" which also in line
>> with what I said that you can use ANY language to write OOP program.
>>
>> Wait, I think I get it. Are you making a distinction between object
>> oriented /languages/ and object oriented /programs/ (which may or may not
>> be written in an object oriented language)?
>>
>> For example, from my interpretation of your definition, Java and C++
>> would be considered object oriented languages, because they favor class
>> inheritance over composition. But a language like Scheme or JavaScript
>> would not be considered an object oriented language because they do not
>> have traditional class inheritance.
>>
>> However, it seems like you are saying that you can write an object
>> oriented /program/ in any of the above languages? Each of the above
>> languages allows you to create "things" that have internal mutable state,
>> and can receive messages, which seems like a pretty good definition of an
>> object :D Hence, object oriented programming is possible.
>>
>> I don't really have an opinion on this. I just want to know if my
>> interpretation of your opinion was close, or way off base hehe.
>>
>> On Friday, January 1, 2021 at 6:05:07 AM UTC-8 Space A. wrote:
>>
>>> Ok I see you change a little bit your position, so I only comment on
>>> this:
>>>
>>> > His verbatim quote is "Go is a profoundly object oriented language.
>>> Arguably more object oriented than say Java or C++". That clearly
>>> contradicts your statement that Go is not an OOP language. He also goes to
>>> great length to say that Go does not have inheritance (in favor of
>>> composition), which, together with the first one, clearly implies that he
>>

Re: [go-nuts] Re: Generics, please go away!

[Space A.]

 > Wait, I think I get it. Are you making a distinction between object
oriented /languages/ and object oriented /programs/ (which may or may not
be written in an object oriented language)?
You are absolutely correct, my friend, so you see, OOP is just a paradigm
in software development. Program can be entirely OOP, or partially, such as
module, or library. And you have tools such as programming languages. When
these languages provide you with instruments for building your OOP program
*out of the box*, being a first-class citizens, you could call that
language OOP. Key feature of major OOP languages is inheritance and all
supporting stuff. But you can use non-OOP language such as C, just that you
will need to add some moving parts yourself instead of using what's given
by language.

Same with CSP. Go is often called a CSP language, or language with CSP
capabilities, because it has all needed features, such as goroutines and
channels out of the box as first class objects. But this doesn't mean you
cannot write CSP program in any other language, you can, but you will
sometimes have to invent a wheel.


> For example, from my interpretation of your definition, Java and C++
would be considered object oriented languages, because they favor class
inheritance over composition. But a language like Scheme or JavaScript
would not be considered an object oriented language because they do not
have traditional class inheritance.
Exactly. Thank you for giving me hope that at the end at least some of us
living on the same planet.


пт, 1 янв. 2021 г. в 19:07, Beka Westberg :

> > First of all I feel it's more rhetoric, it's same as "Less is
> exponentially more", and "[Go] ... Arguably more object oriented than say
> Java or C++ ". I believe if you think logically "less" could not be "more",
> right, and you wouldn't insist on that? Same goes to the statement that Go
> is more object oriented. What I think he meant was "Go has even better
> compatibilities even for OOP because of composition" which also in line
> with what I said that you can use ANY language to write OOP program.
>
> Wait, I think I get it. Are you making a distinction between object
> oriented /languages/ and object oriented /programs/ (which may or may not
> be written in an object oriented language)?
>
> For example, from my interpretation of your definition, Java and C++ would
> be considered object oriented languages, because they favor class
> inheritance over composition. But a language like Scheme or JavaScript
> would not be considered an object oriented language because they do not
> have traditional class inheritance.
>
> However, it seems like you are saying that you can write an object
> oriented /program/ in any of the above languages? Each of the above
> languages allows you to create "things" that have internal mutable state,
> and can receive messages, which seems like a pretty good definition of an
> object :D Hence, object oriented programming is possible.
>
> I don't really have an opinion on this. I just want to know if my
> interpretation of your opinion was close, or way off base hehe.
>
> On Friday, January 1, 2021 at 6:05:07 AM UTC-8 Space A. wrote:
>
>> Ok I see you change a little bit your position, so I only comment on this:
>>
>> > His verbatim quote is "Go is a profoundly object oriented language.
>> Arguably more object oriented than say Java or C++". That clearly
>> contradicts your statement that Go is not an OOP language. He also goes to
>> great length to say that Go does not have inheritance (in favor of
>> composition), which, together with the first one, clearly implies that he
>> is contradicting your assertion that "OOP is all about inheritance".
>>
>> > I don't see a lot of room for interpretation here.
>>
>> Well, I do. I do believe if you truly think he meant "Go is OOP language"
>> and continue insisting you are wrong.
>>
>> 1. First of all I feel it's more rhetoric, it's same as "Less is
>> exponentially more", and "[Go] ... Arguably more object oriented than say
>> Java or C++ ". I believe if you think logically "less" could not be "more",
>> right, and you wouldn't insist on that? Same goes to the statement that Go
>> is more object oriented. What I think he meant was "Go has even better
>> compatibilities even for OOP because of composition" which also in line
>> with what I said that you can use ANY language to write OOP program.
>> 2. There is FAQ question and answer, and I do believe Rob took part in
>> answering FAQ, and this one in particular.
>>
>> Anyways as you said in the beginning of thread, Go is no a 

Re: [go-nuts] Generics, please go away!

[Space A.]

That's fine so we disagree on that. An you also seem to disagree on FAQ (I
know you read it, that's for other readers):
https://golang.org/doc/faq#Is_Go_an_object-oriented_language

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

пт, 1 янв. 2021 г. в 21:44, robert engels :

> I hate to chime in here, but Go by the industry accepted definition - at
> least based on my 30+ years experience - is that Go is clearly an OOP
> language.
>
> It has “instances” coupled with “behavior”. That is, given a struct
> instance I can call a method “on it” declared by its definition. Other OOP
> languages don’t require the definition and can create instance methods
> dynamically.
>
> This differs from a language like Assembly, C, Cobol (prior 2002), or
> Fortran (prior 2003).
>
> For example, C has instances but no methods.
>
> On Jan 1, 2021, at 6:56 AM, Space A.  wrote:
>
> > Javascript is an incredibly popular language with non-inheritance OOP.
> Or, at least, no inheritance at the type-level (so either way, invalidating
> your statement that OOP is about type-hierarchies).
> This is debatable but JS is a non-OOP language. And yet if you wonder,
> there is no definition of what OOP language is. Give it any, I don't mind.
> But it seems to most of us it's quite clear (by major examples like C++ or
> Java) until we start arguing just for arguing.
>
> > Repetition does not make a false statement true. Instead of copy-pasting
> yourself, it would be prudent to cite sources. For example, is there any
> text book that agrees with your definition of OOP?
> What exactly you disagree on? I will copy and paste once again for your
> convenience =)
> Classes (like in Java) vs structs (like in Go) is about inheritance vs
> composition, not about attaching fields and methods. Inheritance implies
> type hierarchy, child and parent, virtual functions, abstract and final
> implementations and so on so forth to keep this all of this manageable.
>
> You disagree on a statement that composition is not inheritance? Or that
> inheritance implies type hierarchy and vise versa? Maybe you disagree with
> Rob Pike who made statements quite similar to what I said regarding
> composition in his quote I given above? Or just arguing for arguing? I just
> don't understand your pathos here.
>
> > One thing that is conspicuously absent from this quote, of course, is
> the term "Object oriented programming" (or even just "Object"). FTR, if you
> quote Rob Pike, you should also be aware that he has always staunchly
> defended the stance that Go is an OOP language:
> That's ridiculous. There is a question in FAQ. And answer you are aware
> of, which says Go is not OOP, which Rop Pike for sure aware of as well. And
> his wording in that video means not how you trying to interpret.
>
> > But either way, if you don't mind me asking: What exactly does any of
> this have to do with generics?
> Good question, ask Alex Besogonov, because he started this arguing that Go
> has classes (opponent meant he doesn't want making Go like C++/Java).
>
>
>
>
> пт, 1 янв. 2021 г. в 05:16, Axel Wagner :
>
>> On Fri, Jan 1, 2021 at 1:23 AM Space A.  wrote:
>>
>>> > Sorry to disappoint you (actually, no, not sorry) but OOP has nothing
>>> to do with inheritance. It's a common feature in object-oriented
>>> programming but it's not essential.
>>> > Moreover, Go has inheritance as well (struct embedding and interface
>>> inheritance), making it a fairly typical example. The only significant
>>> difference is that Go has structural typing, instead of manually
>>> declaration of implemented interfaces.
>>>
>>> You don't disappoint me by repeating wrong statements.
>>>
>>> As I said, OOP (if we talk about language, not a program written in OOP
>>> paradigm, because you can use ANY language for that) is all about
>>> inheritance. Period. Proof - take any major OOP language and see how it's
>>> done, what's in its heart.
>>>
>>
>> Javascript is an incredibly popular language with non-inheritance OOP.
>> Or, at least, no inheritance at the type-level (so either way, invalidating
>> your statement that OOP is about type-hierarchies).
>>
>> Secondly, and I copy-paste myself here:
>>> Classes (like in Java) vs structs (like in Go) is about inheritance vs
>>> composition, not about attaching fields and methods. Inheritance implies
>>> type hierarchy, child and parent, virtual functions, abstract and final
>>> implementatio

Re: [go-nuts] Re: Generics, please go away!

[Space A.]

Actually not "people mean the literal opposite of what they say", but
"people interpret wrongly when trying to read literally". At least I can
imagine myself saying something similar to "Go is more object oriented than
..." if it's not regarding general classification of languages. Maybe I
even did that, lol.



пт, 1 янв. 2021 г. в 17:30, Axel Wagner :

> On Fri, Jan 1, 2021 at 3:04 PM Space A.  wrote:
>
>> > I don't see a lot of room for interpretation here.
>>
>> Well, I do. I do believe if you truly think he meant "Go is OOP language"
>> and continue insisting you are wrong.
>>
>
> Okay. I don't believe "people mean the literal opposite of what they say"
> is a POV that can be argued with.
>
>
>>
>> 1. First of all I feel it's more rhetoric, it's same as "Less is
>> exponentially more", and "[Go] ... Arguably more object oriented than say
>> Java or C++ ". I believe if you think logically "less" could not be "more",
>> right, and you wouldn't insist on that? Same goes to the statement that Go
>> is more object oriented. What I think he meant was "Go has even better
>> compatibilities even for OOP because of composition" which also in line
>> with what I said that you can use ANY language to write OOP program.
>> 2. There is FAQ question and answer, and I do believe Rob took part in
>> answering FAQ, and this one in particular.
>>
>> Anyways as you said in the beginning of thread, Go is no a religion, Rob
>> is not Jesus, he is alive and he can explain his position if it makes any
>> sense. Maybe I'm wrong and don't understand something, that's possible. So
>> I'm not arguing for the sake of arguing.
>>
>>
>>
>>
>>
>> пт, 1 янв. 2021 г. в 16:48, Axel Wagner :
>>
>>> On Fri, Jan 1, 2021 at 1:57 PM Space A.  wrote:
>>>
>>>> > Javascript is an incredibly popular language with non-inheritance
>>>> OOP. Or, at least, no inheritance at the type-level (so either way,
>>>> invalidating your statement that OOP is about type-hierarchies).
>>>>
>>> This is debatable but JS is a non-OOP language.
>>>>
>>>
>>> That's certainly a valid opinion to hold. I don't believe it,
>>> empirically, agrees with the common wisdom around it, though.
>>>
>>>
>>>> And yet if you wonder, there is no definition of what OOP language is.
>>>> Give it any, I don't mind. But it seems to most of us it's quite clear (by
>>>> major examples like C++ or Java) until we start arguing just for arguing.
>>>>
>>>
>>> With this, I agree. Note, again, that it doesn't actually *matter* for
>>> the question of whether or not Go should get generics, whether we call it
>>> an OOP language or not. And yet, it has become a point of argument in this
>>> thread - AFAICT, purely for the sake of arguing.
>>>
>>> > Repetition does not make a false statement true. Instead of
>>>> copy-pasting yourself, it would be prudent to cite sources. For example, is
>>>> there any text book that agrees with your definition of OOP?
>>>> What exactly you disagree on? I will copy and paste once again for your
>>>> convenience =)
>>>>
>>>
>>> There really is no need (though I recognize what you are trying to do).
>>> Let me quote a couple of your statements that I disagree with:
>>> • "Go doesn't have classes and is not an OOP language."
>>> • "Oh my... It is pure sophistic nonsense. OOP is all about inheritance.
>>> Not just whether you have "objects" in a language spec or not."
>>> • "As I said, OOP (if we talk about language, not a program written in
>>> OOP paradigm, because you can use ANY language for that) is all about
>>> inheritance."
>>>
>>> And in the interest of clarity and to illustrate that I'm not just
>>> trying to argue for the sake of argument: I do agree with you that Go
>>> favors composition over inheritance. And I do agree that inheritance based
>>> OOP prioritizes type-hierarchies.
>>>
>>>
>>>> Maybe you disagree with Rob Pike who made statements quite similar to
>>>> what I said regarding composition in his quote I given above?
>>>>
>>>
>>> If we are making an appeal to authority, I thnik you'll find he made
>>> statements that directly contradict the ones I quoted above as disagree
>>> with. And he made statements

Re: [go-nuts] Re: Generics, please go away!

[Space A.]

Ok I see you change a little bit your position, so I only comment on this:

> His verbatim quote is "Go is a profoundly object oriented language.
Arguably more object oriented than say Java or C++". That clearly
contradicts your statement that Go is not an OOP language. He also goes to
great length to say that Go does not have inheritance (in favor of
composition), which, together with the first one, clearly implies that he
is contradicting your assertion that "OOP is all about inheritance".

> I don't see a lot of room for interpretation here.

Well, I do. I do believe if you truly think he meant "Go is OOP language"
and continue insisting you are wrong.

1. First of all I feel it's more rhetoric, it's same as "Less is
exponentially more", and "[Go] ... Arguably more object oriented than say
Java or C++ ". I believe if you think logically "less" could not be "more",
right, and you wouldn't insist on that? Same goes to the statement that Go
is more object oriented. What I think he meant was "Go has even better
compatibilities even for OOP because of composition" which also in line
with what I said that you can use ANY language to write OOP program.
2. There is FAQ question and answer, and I do believe Rob took part in
answering FAQ, and this one in particular.

Anyways as you said in the beginning of thread, Go is no a religion, Rob is
not Jesus, he is alive and he can explain his position if it makes any
sense. Maybe I'm wrong and don't understand something, that's possible. So
I'm not arguing for the sake of arguing.





пт, 1 янв. 2021 г. в 16:48, Axel Wagner :

> On Fri, Jan 1, 2021 at 1:57 PM Space A.  wrote:
>
>> > Javascript is an incredibly popular language with non-inheritance OOP.
>> Or, at least, no inheritance at the type-level (so either way, invalidating
>> your statement that OOP is about type-hierarchies).
>>
> This is debatable but JS is a non-OOP language.
>>
>
> That's certainly a valid opinion to hold. I don't believe it, empirically,
> agrees with the common wisdom around it, though.
>
>
>> And yet if you wonder, there is no definition of what OOP language is.
>> Give it any, I don't mind. But it seems to most of us it's quite clear (by
>> major examples like C++ or Java) until we start arguing just for arguing.
>>
>
> With this, I agree. Note, again, that it doesn't actually *matter* for the
> question of whether or not Go should get generics, whether we call it an
> OOP language or not. And yet, it has become a point of argument in this
> thread - AFAICT, purely for the sake of arguing.
>
> > Repetition does not make a false statement true. Instead of copy-pasting
>> yourself, it would be prudent to cite sources. For example, is there any
>> text book that agrees with your definition of OOP?
>> What exactly you disagree on? I will copy and paste once again for your
>> convenience =)
>>
>
> There really is no need (though I recognize what you are trying to do).
> Let me quote a couple of your statements that I disagree with:
> • "Go doesn't have classes and is not an OOP language."
> • "Oh my... It is pure sophistic nonsense. OOP is all about inheritance.
> Not just whether you have "objects" in a language spec or not."
> • "As I said, OOP (if we talk about language, not a program written in OOP
> paradigm, because you can use ANY language for that) is all about
> inheritance."
>
> And in the interest of clarity and to illustrate that I'm not just trying
> to argue for the sake of argument: I do agree with you that Go favors
> composition over inheritance. And I do agree that inheritance based OOP
> prioritizes type-hierarchies.
>
>
>> Maybe you disagree with Rob Pike who made statements quite similar to
>> what I said regarding composition in his quote I given above?
>>
>
> If we are making an appeal to authority, I thnik you'll find he made
> statements that directly contradict the ones I quoted above as disagree
> with. And he made statements that support the ones I agree with.
>
>
>> That's ridiculous. There is a question in FAQ. And answer you are aware
>> of, which says Go is not OOP, which Rop Pike for sure aware of as well. And
>> his wording in that video means not how you trying to interpret.
>>
>
> His verbatim quote is "Go is a profoundly object oriented language.
> Arguably more object oriented than say Java or C++". That clearly
> contradicts your statement that Go is not an OOP language. He also goes to
> great length to say that Go does not have inheritance (in favor of
> composition), which, together with the first one, clearly implies that he
> is contradicting y

Re: [go-nuts] Generics - please provide real life problems

[Space A.]

> The real magic is being able to discern what the things are that can be
useful enough to justify their cost, not just to stop. Stopping is trivial
- you could just set the Go repository to archive mode and it will never
change again.
One of the key Go values is simplicity. Keeping langage spec relatively
small and code clean and readable. So if you justify from that angle you
should say stop to any form of generic programming.

> This thread, however, asserted that there are *no* real-world use-cases
for generics. That's clearly wrong. The next thread might try to instead
make the argument that there are not *enough* real-world use-cases. As I
said, I can't really argue about that, I'm lacking quantitative data. But
I'm looking forward to someone providing that.

There is no real world problem *in this thread*. That's true. However,
there are some in the universe, that's for sure. Even if there weren't you
could have always invented one. =) Problem is not in proving that, but that
generics will be used mostly to fight with ephemeral "interfaces are bad",
"we have a type safety problem" (what?), reducing amount of "repetitive"
code, abandoning "clear is better than clever" principle, and for infinite
micro optimizations for every single nanosecond.


пт, 1 янв. 2021 г. в 16:20, Axel Wagner :

> On Fri, Jan 1, 2021 at 2:14 PM Space A.  wrote:
>
>> So magic here is being able to say "stop".
>>
>
> The real magic is being able to discern what the things are that can be
> useful enough to justify their cost, not just to stop. Stopping is trivial
> - you could just set the Go repository to archive mode and it will never
> change again.
>
> This thread, however, asserted that there are *no* real-world use-cases
> for generics. That's clearly wrong. The next thread might try to instead
> make the argument that there are not *enough* real-world use-cases. As I
> said, I can't really argue about that, I'm lacking quantitative data. But
> I'm looking forward to someone providing that.
>
> Code in these bloated ecosystems over time becomes unreadable so that in
>> many many cases it's easier to rewrite even very complex applications with
>> thousands of man hours spent on, just from the scratch, than to try to
>> read, understand and improve it evolutionarily. That's the reality. On the
>> other hand Go has never been posed to benefit everyone. Covering each and
>> every use case is not in its values. "Less is exponentially more".
>>
>> пт, 1 янв. 2021 г. в 13:24, 'Axel Wagner' via golang-nuts <
>> golang-nuts@googlegroups.com>:
>>
>>> On Fri, Jan 1, 2021 at 8:15 AM Robert Engels 
>>> wrote:
>>>
>>>> Of course. But you don’t design a language (or any other product) for
>>>> the 5% - you design it for the 95 (80?} percent - if you want you have
>>>> customers/users and stay relevant (in business).
>>>>
>>>
>>> I take it. I don't have data to make quantitative statements, so I can't
>>> argue whether or not generics are useful in 5%, or 25% or 90%.
>>> But at least you and me seem to agree that there *are* real life
>>> use-cases for generics (which is what this thread tried to call into
>>> question).
>>>
>>>
>>>
>>>>
>>>> On Dec 31, 2020, at 8:39 PM, 'Axel Wagner' via golang-nuts <
>>>> golang-nuts@googlegroups.com> wrote:
>>>>
>>>> 
>>>> On Thu, Dec 31, 2020 at 6:51 PM robert engels 
>>>> wrote:
>>>>
>>>>> Go has been in existence for 10+ years and has fairly wide adoption in
>>>>> some areas - so it is not hard to make the case that generics are “not an
>>>>> important thing”
>>>>>
>>>>
>>>> This has been brought up in That Other Thread, so let me copy what I
>>>> said there (you didn't respond to that particular point, even though you
>>>> replied to the E-Mail, so I assume you've already read it):
>>>>
>>>> Of course, this doesn't answer how we'd have managed *with* them.
>>>>
>>>> We did manage for decades without general purpose CPUs. We did manage
>>>> for several decades without functions, coroutines or hashtables. We did
>>>> manage for decades without portable programming languages or multi-tasking
>>>> operating systems. We managed for many decades without the internet or the
>>>> world wide web.
>>>>
>>>> In hindsight, though,  "we managed so long without them" doesn't appear
>>>> to be a very convincing argument to not have

Re: [go-nuts] Generics - please provide real life problems

[Space A.]

You will always find use cases for anything even for absolutely useless
things. Because real life is full of paradoxes, and people are always
irrational. And you may be adding features again and again and you still
will have more to add. This way anything including programming language
becomes a bloated mess. So magic here is being able to say "stop". Code in
these bloated ecosystems over time becomes unreadable so that in many many
cases it's easier to rewrite even very complex applications with thousands
of man hours spent on, just from the scratch, than to try to read,
understand and improve it evolutionarily. That's the reality. On the other
hand Go has never been posed to benefit everyone. Covering each and every
use case is not in its values. "Less is exponentially more".

пт, 1 янв. 2021 г. в 13:24, 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com>:

> On Fri, Jan 1, 2021 at 8:15 AM Robert Engels 
> wrote:
>
>> Of course. But you don’t design a language (or any other product) for the
>> 5% - you design it for the 95 (80?} percent - if you want you have
>> customers/users and stay relevant (in business).
>>
>
> I take it. I don't have data to make quantitative statements, so I can't
> argue whether or not generics are useful in 5%, or 25% or 90%.
> But at least you and me seem to agree that there *are* real life use-cases
> for generics (which is what this thread tried to call into question).
>
>
>
>>
>> On Dec 31, 2020, at 8:39 PM, 'Axel Wagner' via golang-nuts <
>> golang-nuts@googlegroups.com> wrote:
>>
>> 
>> On Thu, Dec 31, 2020 at 6:51 PM robert engels 
>> wrote:
>>
>>> Go has been in existence for 10+ years and has fairly wide adoption in
>>> some areas - so it is not hard to make the case that generics are “not an
>>> important thing”
>>>
>>
>> This has been brought up in That Other Thread, so let me copy what I said
>> there (you didn't respond to that particular point, even though you replied
>> to the E-Mail, so I assume you've already read it):
>>
>> Of course, this doesn't answer how we'd have managed *with* them.
>>
>> We did manage for decades without general purpose CPUs. We did manage for
>> several decades without functions, coroutines or hashtables. We did manage
>> for decades without portable programming languages or multi-tasking
>> operating systems. We managed for many decades without the internet or the
>> world wide web.
>>
>> In hindsight, though,  "we managed so long without them" doesn't appear
>> to be a very convincing argument to not have them today.
>>
>>
>>> - depends on what you are trying to do with it and what your perspective
>>> on “the right way” is.
>>>
>>
>> This seems to indicate some progress in mutual understanding - by saying
>> that it depends on what you do with the language, you seem to imply that
>> you understand that other people's use-case might benefit from generics. Am
>> I reading this correctly?
>>
>>
>>>
>>>
>>> On Dec 31, 2020, at 10:54 AM, 'Axel Wagner' via golang-nuts <
>>> golang-nuts@googlegroups.com> wrote:
>>>
>>> On Thu, Dec 31, 2020 at 5:46 PM robert engels 
>>> wrote:
>>>
 I’ll state for the record again, I was originally very dismayed that Go
 did not offer generics - after developing with it for a while that is far
 less of an issue to me than the error handling.

>>>
>>> Just to illustrate that the plural of "anecdote" isn't "data": I was
>>> originally very vehemently opposed to generics in Go, but after using Go
>>> for a bunch of years, I've been missing them often enough that I think they
>>> provide a net-benefit (despite my criticism of this specific design).
>>>
>>> Generics just isn't a "if you use Go long enough you learn they are not
>>> important" thing.
>>>
>>>
 On Dec 31, 2020, at 4:25 AM, 'Axel Wagner' via golang-nuts <
 golang-nuts@googlegroups.com> wrote:

 Hi,

 On Thu, Dec 31, 2020 at 8:59 AM wilk  wrote:

> If 95% of generics are collections the current draft is overkill.
> What about a simplified version with only one generic type (like we do
> with interface{}), without constraint as long as it can compile ?
>

 • "Only one generic type" means you can't write generic maps or graph
 structures
 • "Without constraints" means compilation cost goes up significantly
 (as the compiler needs to completely redo type-checking and compilation for
 each instantiation - instead of only checking that the function adheres to
 the constraints and the type-arguments fulfill it at each call-site. i.e.
 you make an NxM problem out of an N+M problem). It also makes good error
 messages very hard. And the constraints need to be documented anyway (in a
 comment, if nothing else), so that the user knows how to call the function
 - might as well have a standardized, machine-checkable way to express that.

 So even *if* we only consider containers, the complexity of the design
 isn't accidental. There are 

Re: [go-nuts] Re: Generics, please go away!

[Space A.]

> Javascript is an incredibly popular language with non-inheritance OOP.
Or, at least, no inheritance at the type-level (so either way, invalidating
your statement that OOP is about type-hierarchies).
This is debatable but JS is a non-OOP language. And yet if you wonder,
there is no definition of what OOP language is. Give it any, I don't mind.
But it seems to most of us it's quite clear (by major examples like C++ or
Java) until we start arguing just for arguing.

> Repetition does not make a false statement true. Instead of copy-pasting
yourself, it would be prudent to cite sources. For example, is there any
text book that agrees with your definition of OOP?
What exactly you disagree on? I will copy and paste once again for your
convenience =)
Classes (like in Java) vs structs (like in Go) is about inheritance vs
composition, not about attaching fields and methods. Inheritance implies
type hierarchy, child and parent, virtual functions, abstract and final
implementations and so on so forth to keep this all of this manageable.

You disagree on a statement that composition is not inheritance? Or that
inheritance implies type hierarchy and vise versa? Maybe you disagree with
Rob Pike who made statements quite similar to what I said regarding
composition in his quote I given above? Or just arguing for arguing? I just
don't understand your pathos here.

> One thing that is conspicuously absent from this quote, of course, is the
term "Object oriented programming" (or even just "Object"). FTR, if you
quote Rob Pike, you should also be aware that he has always staunchly
defended the stance that Go is an OOP language:
That's ridiculous. There is a question in FAQ. And answer you are aware of,
which says Go is not OOP, which Rop Pike for sure aware of as well. And his
wording in that video means not how you trying to interpret.

> But either way, if you don't mind me asking: What exactly does any of
this have to do with generics?
Good question, ask Alex Besogonov, because he started this arguing that Go
has classes (opponent meant he doesn't want making Go like C++/Java).




пт, 1 янв. 2021 г. в 05:16, Axel Wagner :

> On Fri, Jan 1, 2021 at 1:23 AM Space A.  wrote:
>
>> > Sorry to disappoint you (actually, no, not sorry) but OOP has nothing
>> to do with inheritance. It's a common feature in object-oriented
>> programming but it's not essential.
>> > Moreover, Go has inheritance as well (struct embedding and interface
>> inheritance), making it a fairly typical example. The only significant
>> difference is that Go has structural typing, instead of manually
>> declaration of implemented interfaces.
>>
>> You don't disappoint me by repeating wrong statements.
>>
>> As I said, OOP (if we talk about language, not a program written in OOP
>> paradigm, because you can use ANY language for that) is all about
>> inheritance. Period. Proof - take any major OOP language and see how it's
>> done, what's in its heart.
>>
>
> Javascript is an incredibly popular language with non-inheritance OOP. Or,
> at least, no inheritance at the type-level (so either way, invalidating
> your statement that OOP is about type-hierarchies).
>
> Secondly, and I copy-paste myself here:
>> Classes (like in Java) vs structs (like in Go) is about inheritance vs
>> composition, not about attaching fields and methods. Inheritance implies
>> type hierarchy, child and parent, virtual functions, abstract and final
>> implementations and so on so forth to keep this all of this manageable.
>>
>
> Repetition does not make a false statement true. Instead of copy-pasting
> yourself, it would be prudent to cite sources. For example, is there any
> text book that agrees with your definition of OOP?
>
> If you don't understand what it means, please study a little bit (with all
>> respect and blabla, I also learn all the time). Because these two
>> approaches are different.
>>
>> Here is some small quote and link which I think can help:
>>
>> My late friend Alain Fournier once told me that he considered the lowest
>>> form of academic work to be taxonomy. And you know what? Type hierarchies
>>> are just taxonomy. You need to decide what piece goes in what box, every
>>> type's parent, whether A inherits from B or B from A.  Is a sortable array
>>> an array that sorts or a sorter represented by an array? If you believe
>>> that types address all design issues you must make that decision.
>>>
>> I believe that's a preposterous way to think about programming. What
>>> matters isn't the ancestor relations between things but what they can do
>>> for you.
>>>
>>> That, of course, is where interfaces come into Go. But they're part

Re: [go-nuts] Re: Generics, please go away!

[Space A.]

> Sorry to disappoint you (actually, no, not sorry) but OOP has nothing to
do with inheritance. It's a common feature in object-oriented programming
but it's not essential.
> Moreover, Go has inheritance as well (struct embedding and interface
inheritance), making it a fairly typical example. The only significant
difference is that Go has structural typing, instead of manually
declaration of implemented interfaces.

You don't disappoint me by repeating wrong statements.

As I said, OOP (if we talk about language, not a program written in OOP
paradigm, because you can use ANY language for that) is all about
inheritance. Period. Proof - take any major OOP language and see how it's
done, what's in its heart.

Secondly, and I copy-paste myself here:
Classes (like in Java) vs structs (like in Go) is about inheritance vs
composition, not about attaching fields and methods. Inheritance implies
type hierarchy, child and parent, virtual functions, abstract and final
implementations and so on so forth to keep this all of this manageable.

If you don't understand what it means, please study a little bit (with all
respect and blabla, I also learn all the time). Because these two
approaches are different.

Here is some small quote and link which I think can help:

My late friend Alain Fournier once told me that he considered the lowest
> form of academic work to be taxonomy. And you know what? Type hierarchies
> are just taxonomy. You need to decide what piece goes in what box, every
> type's parent, whether A inherits from B or B from A.  Is a sortable array
> an array that sorts or a sorter represented by an array? If you believe
> that types address all design issues you must make that decision.
>
I believe that's a preposterous way to think about programming. What
> matters isn't the ancestor relations between things but what they can do
> for you.
>
> That, of course, is where interfaces come into Go. But they're part of a
> bigger picture, the true Go philosophy.
> If C++ and Java are about type hierarchies and the taxonomy of types, Go
> is about composition.
> Doug McIlroy, the eventual inventor of Unix pipes, wrote in 1964 (!):
>
> We should have some ways of coupling programs like garden hose--screw in
> another segment when it becomes necessary to massage data in another way.
> This is the way of IO also.
>
> That is the way of Go also. Go takes that idea and pushes it very far. It
> is a language of composition and coupling.
> The obvious example is the way interfaces give us the composition of
> components. It doesn't matter what that thing is, if it implements method M
> I can just drop it in here.
> Another important example is how concurrency gives us the composition of
> independently executing computations.
> And there's even an unusual (and very simple) form of type composition:
> embedding.
> These compositional techniques are what give Go its flavor, which is
> profoundly different from the flavor of C++ or Java programs.
>

https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html





чт, 31 дек. 2020 г. в 23:27, Alex Besogonov :

> On Wednesday, December 30, 2020 at 12:23:35 PM UTC-8 Space A. wrote:
>
>> > OOP isn't specific about how inheritance is handled (or if it is even
>> supported)
>> Oh my... It is pure sophistic nonsense. OOP is all about inheritance. Not
>> just whether you have "objects" in a language spec or not.
>>
> Sorry to disappoint you (actually, no, not sorry) but OOP has nothing to
> do with inheritance. It's a common feature in object-oriented programming
> but it's not essential.
>
> Moreover, Go has inheritance as well (struct embedding and interface
> inheritance), making it a fairly typical example. The only significant
> difference is that Go has structural typing, instead of manually
> declaration of implemented interfaces.
>
> > But on the topic of generics, this entire thread seems alarmist.
>> Generics will open a huge door for libraries to be written that will make
>> our lives easier.  I'm thinking specifically about data processing and
>> machine learning.  A lot of devs use Python right now for this which leads
>> to duplication of code across languages.  Complex algorithms will be able
>> to be shared without hacky type conversions wrapping every function call.
>> Who is "yours"? You talk about Python so just go ahead and use Python if
>> it serves you, convince your team that Python is better, whatever.
>>
> You know that this argument can be applied to you as well?
>
>
>> среда, 30 декабря 2020 г. в 22:46:12 UTC+3, nichol...@gmail.com:
>>
>>> OOP isn't specific about how inheritance is handled (or if it is even
>>> supported).  The basic definition is objects with 

Re: [go-nuts] Generics - please provide real life problems

[Space A.]

> hi Space, 
Hey,

> i do not care about this discussion in general 
> i would not want to enter into a discussion with you 

So it's up to you, isn't it? Should I invite you? Or maybe anyone else 
should? I don't know you and don't care about your existence (as you said, 
I don't mean any disrespect, just a fact). I would say that in my 
experience whether you or anyone else enters a discussion depends on 
whether you have anything in mind, on the subject and appropriate 
arguments, or not. Interestingly, but nobody in this and adjacent thread 
who set him(-her)self against generics didn't attempt any personal attack. 
And in this thread you're 3rd person who have nothing to say in general, 
but a lot to say about me. =) Not knowing me at all, even my name. 

So have you read my comment, do you have any arguments regarding my point 
that most of people here who are pro-generics don't understand what *real 
world* problems are and not facing this class of problems? Lets' talk about 
this. All of this (copied):
> > "runtime type-casting" 
> > "type safety something" 
> > "boilerplate" 
> > "amount of code" 
> > "benefit something" 
> > "greatly simplified" (for whom?) 

translates to not more than just a simple implication that "generics are 
better". As simple as that. So the problems people trying to "solve" are a 
kind of very general, imaginary and ephemeral things like:
"generics are better than runtime"
"generics are better than interfaces"
"generics produces less code which is better"
"generics produces smarter code" (Clear is better than clever? No, never 
heard!)
 "generics gives better performance"
etc

and so one so forth. Which are just not correct.

*Not* *a* *single* *real* *world* *problem* in any of presented case. Did I 
miss one? Please point on it! So why shouldn't I or anyone else say it's a 
*bullshit* after all (but I didn't)? After all your attacks?

And all you can say: "i would not want to enter into a discussion with you 
based on the general tone of your messages, regardless of argument or 
subject ". 

Ok, do not.


четверг, 31 декабря 2020 г. в 17:58:24 UTC+3, mb0: 

> hi Space, 
>
> i do not care about this discussion in general and learned to trust the 
> go developers to be thoughtful and reasonable. 
>
> i wouldn't write this normally, but in case you are not aware it might 
> actually help: i did read the last couple of your messages to this list 
> again and came to the conclusion that i would not want to enter into a 
> discussion with you based on the general tone of your messages, 
> regardless of argument or subject. 
>
> i don't mean any disrespect. the advice by Tyler is well meaning and 
> will certainly be good to follow generally and by everyone: 
>
> "I think your arguments would gain quite a bit more traction on this 
> list if you presented them in a more respectful way." 
>
> a good exercise would be to review your messages from a different point 
> of view. read them as if addressed to you and decide whether you would 
> want to reply yourself. 
>
> anyway, have a happy new year everyone! 
>
> On 31.12.20 13:55, Space A. wrote: 
> > Hi, 
> > ok, so please read it finally and tell which point exactly you think was 
> > against CoC and in what of my messages and in which exact thread, but do 
> > not put my words out of context. And explain why you responded just now, 
> > and to my message to a person who obviously *violated* its terms by 
> > aggressively turning to my personality. 
> > 
> > Do you protect this aggressive behavior just because you pro-generics 
> > and silently hate everything I will say (and me personally)? Because if 
> > you do, it's quite stupid. But I hope it's not. 
> > 
> > 
> > чт, 31 дек. 2020 г. в 07:51, Tyler Compton  > <mailto:xav...@gmail.com>>: 
> > 
> > Space A, 
> > 
> > So switching from subject to my personality and telling me what 
> > I should and what shouldn't, to whom to listen, and what to read 
> > is something in line with "code of conduct" which you appeal as 
> > the argument of last resort? 
> > 
> > 
> > I've seen how you carry yourself on this list, and you really should 
> > read the code of conduct. I think your arguments would gain quite a 
> > bit more traction on this list if you presented them in a more 
> > respectful way. 
> > 
> > On Wed, Dec 30, 2020 at 3:47 PM Space A.  > <mailto:reexi...@gmail.com>> wrote: 
> > 
> > Nice. 
> > 
> > > You should listen to people who have been doing this much 
> > longer 

Re: [go-nuts] Generics - please provide real life problems

[Space A.]

Hi,
ok, so please read it finally and tell which point exactly you think was
against CoC and in what of my messages and in which exact thread, but do
not put my words out of context. And explain why you responded just now,
and to my message to a person who obviously *violated* its terms by
aggressively turning to my personality.

Do you protect this aggressive behavior just because you pro-generics and
silently hate everything I will say (and me personally)? Because if you do,
it's quite stupid. But I hope it's not.


чт, 31 дек. 2020 г. в 07:51, Tyler Compton :

> Space A,
>
>
>> So switching from subject to my personality and telling me what I should
>> and what shouldn't, to whom to listen, and what to read is something in
>> line with "code of conduct" which you appeal as the argument of last resort?
>>
>
> I've seen how you carry yourself on this list, and you really should read
> the code of conduct. I think your arguments would gain quite a bit more
> traction on this list if you presented them in a more respectful way.
>
> On Wed, Dec 30, 2020 at 3:47 PM Space A.  wrote:
>
>> Nice.
>>
>> > You should listen to people who have been doing this much longer than
>> you
>> Thanks, are you sure you know for how long I've been doing *this* to be
>> able to compare?
>> > before discarding all their points as "bullshit"
>> Have *you* actually read and listened because this is not what I've said?
>> > and you should probably review the community code of conduct
>> So switching from subject to my personality and telling me what I should
>> and what shouldn't, to whom to listen, and what to read is something in
>> line with "code of conduct" which you appeal as the argument of last resort?
>>
>>
>> This was actually my first comment on this particular topic. So yea, I
>> read and listened before replying. I could have replied to everyone and
>> explained in detail, but I value the time of my opponents. And my own time,
>> tbh.
>>
>>
>> чт, 31 дек. 2020 г. в 00:03, David Riley :
>>
>>> This topic has shown little other than that a few people here are
>>> unwilling to consider points of view other than their own and declare that
>>> very real problems are not real.
>>>
>>> You should listen to people who have been doing this much longer than
>>> you have before discarding all their points as "bullshit", and you should
>>> probably review the community code of conduct.
>>>
>>> If you've got nothing constructive to contribute, why bother?
>>>
>>>
>>> - Dave
>>>
>>>
>>> > On Dec 30, 2020, at 3:53 PM, Space A.  wrote:
>>> >
>>> > "runtime type-casting"
>>> > "type safety something"
>>> > "boilerplate"
>>> > "amount of code"
>>> > "benefit something"
>>> > "greatly simplified" (for whom?)
>>> >
>>> > This topic has clearly shown that most people pro-generic have no
>>> *real world* problems that they struggle to solve, yet most of them don't
>>> even understand what *real world* problems are.
>>>
>>> --
>> 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/CADKwOTek6rrfmMziuj5poy4hAZJ%3DHXsyp-FB96RdUvZ%2BncoJYA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/golang-nuts/CADKwOTek6rrfmMziuj5poy4hAZJ%3DHXsyp-FB96RdUvZ%2BncoJYA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

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

Re: [go-nuts] Generics - please provide real life problems

[Space A.]

Nice.

> You should listen to people who have been doing this much longer than you
Thanks, are you sure you know for how long I've been doing *this* to be
able to compare?
> before discarding all their points as "bullshit"
Have *you* actually read and listened because this is not what I've said?
> and you should probably review the community code of conduct
So switching from subject to my personality and telling me what I should
and what shouldn't, to whom to listen, and what to read is something in
line with "code of conduct" which you appeal as the argument of last resort?


This was actually my first comment on this particular topic. So yea, I read
and listened before replying. I could have replied to everyone and
explained in detail, but I value the time of my opponents. And my own time,
tbh.


чт, 31 дек. 2020 г. в 00:03, David Riley :

> This topic has shown little other than that a few people here are
> unwilling to consider points of view other than their own and declare that
> very real problems are not real.
>
> You should listen to people who have been doing this much longer than you
> have before discarding all their points as "bullshit", and you should
> probably review the community code of conduct.
>
> If you've got nothing constructive to contribute, why bother?
>
>
> - Dave
>
>
> > On Dec 30, 2020, at 3:53 PM, Space A.  wrote:
> >
> > "runtime type-casting"
> > "type safety something"
> > "boilerplate"
> > "amount of code"
> > "benefit something"
> > "greatly simplified" (for whom?)
> >
> > This topic has clearly shown that most people pro-generic have no *real
> world* problems that they struggle to solve, yet most of them don't even
> understand what *real world* problems are.
>
>

-- 
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/CADKwOTek6rrfmMziuj5poy4hAZJ%3DHXsyp-FB96RdUvZ%2BncoJYA%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Space A.]

"runtime type-casting"
"type safety something" 
"boilerplate"
"amount of code"
"benefit something"
"greatly simplified" (for whom?)

This topic has clearly shown that most people pro-generic have no *real 
world* problems that they struggle to solve, yet most of them don't even 
understand what *real world* problems are.

PS: What about "Clear is better than clever"? What about to try to apply 
some creativity rather than follow one single pattern?
среда, 30 декабря 2020 г. в 21:53:42 UTC+3, Jan Mercl: 

> On Wed, Dec 30, 2020 at 7:38 PM Ian Lance Taylor  wrote:
>
> > I don't think this is accurate. Surveys express a clear and
> > consistent desire for generics that is far ahead of requests for
> > operator overloading or other language features.
>
> No ordering or quantitative comparison was implied. Just that one can
> always find people wanting well known features from other languages.
>
> > (To avoid
> > misunderstanding I'll say again that changes to the Go language are
> > not driven by polls.)
>
> I know that. The point was actually about that very fact - and its
> contrast wrt arguments like "folks want XYZ". But I may have not
> expressed it clearly enough.
>

-- 
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/49eaf9fd-ee2b-4b48-8ffc-43d9e805c510n%40googlegroups.com.

[go-nuts] Re: Generics, please go away!

[Space A.]

> OOP isn't specific about how inheritance is handled (or if it is even 
supported) 
Oh my... It is pure sophistic nonsense. OOP is all about inheritance. Not 
just whether you have "objects" in a language spec or not.

> But on the topic of generics, this entire thread seems alarmist.  
Generics will open a huge door for libraries to be written that will make 
our lives easier.  I'm thinking specifically about data processing and 
machine learning.  A lot of devs use Python right now for this which leads 
to duplication of code across languages.  Complex algorithms will be able 
to be shared without hacky type conversions wrapping every function call. 
Who is "yours"? You talk about Python so just go ahead and use Python if it 
serves you, convince your team that Python is better, whatever.



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

> OOP isn't specific about how inheritance is handled (or if it is even 
> supported).  The basic definition is objects with fields and methods, and 
> being able to address the itself (typically using 'this' or 'self', but Go 
> is unique in that you define what to call the object).  It does composition 
> differently than most languages, but the functional needs are met.
>
> But on the topic of generics, this entire thread seems alarmist.  Generics 
> will open a huge door for libraries to be written that will make our lives 
> easier.  I'm thinking specifically about data processing and machine 
> learning.  A lot of devs use Python right now for this which leads to 
> duplication of code across languages.  Complex algorithms will be able to 
> be shared without hacky type conversions wrapping every function call.  
> We'll be able to use things like trees as simply as we use maps or slices.  
> I don't think we'll see the language turn into the grossness that is Java 
> or C++ because of it.
>
> On Wednesday, December 30, 2020 at 4:27:15 AM UTC-8 Space A. wrote:
>
>> Go doesn't have classes and is not an OOP language.
>>
>> Classes (like in Java) vs structs (like in Go) is about inheritance vs 
>> composition, not about attaching fields and methods. Inheritance implies 
>> type hierarchy, child and parent, virtual functions, abstract and final 
>> implementations and so on so forth to keep this all of this manageable.
>>
>>
>>
>> вторник, 29 декабря 2020 г. в 23:27:45 UTC+3, Alex Besogonov: 
>>
>>> Please, stop being so condescending to newcomers and non-professional 
>>> developers. Generics as uses by end-users will improve their experience, 
>>> not make it harder.
>>>
>>> (And what is this obsession with "classes"? Go has them - structs with 
>>> methods are classes).
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c6c3473b-7afd-4225-bb82-94b648ae5c1en%40googlegroups.com.

[go-nuts] Re: Generics, please go away!

[Space A.]

Go doesn't have classes and is not an OOP language.

Classes (like in Java) vs structs (like in Go) is about inheritance vs 
composition, not about attaching fields and methods. Inheritance implies 
type hierarchy, child and parent, virtual functions, abstract and final 
implementations and so on so forth to keep this all of this manageable.



вторник, 29 декабря 2020 г. в 23:27:45 UTC+3, Alex Besogonov: 

> Please, stop being so condescending to newcomers and non-professional 
> developers. Generics as uses by end-users will improve their experience, 
> not make it harder.
>
> (And what is this obsession with "classes"? Go has them - structs with 
> methods are classes).
>
> On Tuesday, December 29, 2020 at 1:32:30 AM UTC-8 rickti...@googlemail.com 
> wrote:
>
>> My point of view is that Generics should not become part of the Go 
>> standard library. I appreciate there are use cases where it is very helpful 
>> to have, but I do not believe that adds value to Go. The real value for Go 
>> is it's simplicity, avoidance of generics and avoidance of classes. This 
>> makes the language accessible and approachable to all, which is 
>> increasingly more valuable. Go appeals to new-comers and experienced 
>> developers because it is simple, and comfortable. The rate of uptake in 
>> computing technology is still subject to Moores law, and today we see a new 
>> type of programmer emerging, the 'citizen developer'.  
>>
>> Go follows time proven computational concepts, it does not follow the 
>> 'new paradigm' tribes, it's roots are firmly planted in statically typed 
>> procedural/functional programming techniques, and this maps well to much of 
>> the literature available. The growth of entry level developers ( aka 
>> 'citizen developers' ) will be exponential over the next decade, and in 
>> that landscape it is Go's simplicity that will win the day.
>>
>> On Monday, 28 December 2020 at 17:35:40 UTC L Godioleskky wrote:
>>
>>> " If generics gets added to Go, we're opening a very dangerous door, and
>>> it will be the downfall of Go because - and Robert Griesemer this is
>>> especially addressed to you - what's next then? Seriously, what's next? 
>>> ... "
>>>
>>> .. AI, followed by cryto currency and asexual repoduction
>>> On Tuesday, December 22, 2020 at 5:09:05 AM UTC-5 Martin Hanson wrote:
>>>
 No polls. It's not a matter of majority rule! 

 It's a matter of understanding why generics was left out of Go from the 
 start, like classes was left out of Go. If we start adding stuff that 
 the original developers of Go left out by purpose, we're not 
 understanding the design choices that went into Go, which is exactly 
 what makes Go unique! 

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

 If you want to add generics to Go, if you want to change how errors are 
 handled, if you want X, Y or Z feature that Java, C++, or some other 
 complex language has got, then go use that language! Why are you even 
 here!? 

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

 If generics gets added to Go, we're opening a very dangerous door, and 
 it will be the downfall of Go because - and Robert Griesemer this is 
 especially addressed to you - what's next then? Seriously, what's next? 
 Let the community decide by majority!? Is that how we design a 
 professional programming language now? By majority rule?! NO! The 
 majority is all about hype and shine. 

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

 If generics gets added to Go, we're a big enough part of the community, 
 that passionately hate that, that we can manage to fork Go - which I 
 strongly believe will then be the right thing to do! 

>>>

-- 
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/1261ed9d-2615-4ffd-ba76-016cc07bdbd7n%40googlegroups.com.

Re: [go-nuts] Re: Generics, please go away!

[Space A.]

What a ridiculous bullshit.

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

> Ok maybe this thread has gone on too long.
> Both Java and C++ has benefited greatly from generics and most of their 
> respective communities wouldn't want them gone. I am pretty sure that's 
> what will happen with Go as well. Can we leave it now before we go from 
> "corruption" to whatever hyperbole is next?
>
> On Fri, 25 Dec 2020, 14:10 redsto...@gmail.com,  
> wrote:
>
>> Yes, I agree with you. I use go for more than 3 years. The language is 
>> simple and elegant. But generics will destroy this. Generics bring a lot of 
>> complexity, make language seems ugly with only a few benifit.  They say you 
>> can ignore it. Infact you can not. This language is on the way of  
>> corruption.
>>
>> On Monday, December 21, 2020 at 3:38:54 AM UTC+8 Martin Hanson wrote:
>>
>>> I think people who want generics added to Go should go and program in 
>>> Java or C++. 
>>>
>>> Adding generics to Go will ruin the beautiful simplicity of the language 
>>> and I haven't found a single example in which adding generics to Go pays 
>>> off. 
>>>
>>> Even with the examples of having two almost identical functions reverse 
>>> some list, one of ints and one of strings, seriously!? We already have tons 
>>> and tons of open source reusable code that covers all use cases which 
>>> people complain about. 
>>>
>>> Go was designed without generics purposefully from the start and Go is 
>>> fine just the way it is. 
>>>
>>> Adding generics means that we're opening the door to the beginning of 
>>> bloating Go with all the crap that Java, C++ and all the other complex 
>>> languages has gotten over the years, and Go was designed specifically 
>>> without that clutter. So we add generics, then what? Classes? 
>>>
>>> Adding generics to Go ruins that beautiful simplicity that went into the 
>>> design and the added complexity just isn't worth it! The standard library 
>>> have managed just fine without generics and so have we! 
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/7c3e4e9f-4553-413b-8bdb-57d316ad030cn%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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/b02e918a-a1a6-405f-ab65-814206056b5fn%40googlegroups.com.

Re: [go-nuts] Re: Generics, please go away!

[Space A.]

 > Personally, though, I must say that the generics discussion has been 
going on for 10 years (and even more, if we don't limit ourselves to Go) 
and I don't - personally - believe that there is much hidden cost or 
surprising benefit left to be discovered. 

There is nothing hidden and nothing new! Lol. We know for 100% what will 
happen, all the beauty and simplicity of Go will be lost in one moment, and 
ecosystem will be poisoned forever. And YES, after such a huge change to 
the language, who knows what will be added next. In fact it doesn't matter 
what exactly, because Go was the only language resistant to all of this. 
Until now.

среда, 23 декабря 2020 г. в 16:14:38 UTC+3, axel.wa...@googlemail.com: 

> On Wed, Dec 23, 2020 at 1:17 PM Martin Hanson  
> wrote:
>
>> @Ian, for more than 10 years we have managed nicely without generics.
>>
>
> Of course, this doesn't answer how we'd have managed *with* them.
>
> We did manage for decades without general purpose CPUs. We did manage for 
> several decades without functions, coroutines or hashtables. We did manage 
> for decades without portable programming languages or multi-tasking 
> operating systems. We managed for many decades without the internet or the 
> world wide web.
>
> In hindsight, though,  "we managed so long without them" doesn't appear to 
> be a very convincing argument to not have them today.
>  
>
>> So what is the real true-life problems that validates adding generics
>> to Go? I haven't seen a single example, seriously not one! I have only
>> seen useless examples like the one Ian gives in the talk, which of
>> course I know only serves as an example, but we need real life problems
>> to solve, not theoretical ones.
>>
>
> To me, this suggests that the issue isn't that you haven't seen enough 
> examples, but that you haven't found them convincing you that the benefits 
> outweigh the costs. Which is a completely valid position to take. 
> Obviously, lots of other people (at least some of which you, I think, 
> respect professionally) see that differently. Which is also completely 
> valid. So, confronted with that reality, there are many productive ways to 
> react. Some examples are
>
> • Try to engage in the design process to keep the cost down (i.e. suggest 
> simplifications to the generics design)
> • Try to engage in the design process to increase the benefits (i.e. 
> suggest improvements that increase its power)
> • Accept that it's possible for reasonable people to look at the same 
> problem and proposed solution and agree on what the costs and what the 
> benefits are, but weigh them differently, just as a matter of personal 
> taste or opinion - and thus agree to disagree
> • Try to change the other persons mind about what the costs or benefits 
> are and how much they weigh
>
> Now, that last one *can* be very productive. Especially early on in a 
> discussion, we tend to overlook hidden costs or surprising benefits and 
> having them pointed out can be really helpful. Personally, though, I must 
> say that the generics discussion has been going on for 10 years (and even 
> more, if we don't limit ourselves to Go) and I don't - personally - believe 
> that there is much hidden cost or surprising benefit left to be discovered. 
> And ISTM that swaying someone's mind on them will most likely take more 
> than just outright saying that you don't agree.
>
> So, I guess the question really is, what's the goal? Do you want to get 
> the best language? In that case, I'd personally suggest to focus on 
> improving the generics design. Or do you want to convince others that their 
> valuation of costs and benefits is inaccurate? In that case, I'd personally 
> suggest to try and find new costs or benefits - but keep in mind, that 10 
> years is a lot of time for a lot of them to already have been mentioned a 
> lot. Or do you just want to be heard as being in disagreement? That's also, 
> of course, valid.
>
> What I understand from all of this is that people who are pro-generics are
>> in reality really talking about something that is *nice to have*, not
>> something that is seriously needed and this is where I become really
>> frustrated!
>
>
> I understand this frustration. But it might help to keep in mind that 
> computers are simply nice to have in exactly the same way.
> And I think there's an opportunity to have empathy with people who *are* 
> in favor of generics. Because just like you are frustrated that generics 
> are just nice to have (i.e. you perceive their actual benefit as 
> insignificant), people on the other side of the aisle might be *just as* 
> frustrated by you, because generics are just slightly more complex (i.e. 
> they perceive their actual costs as insignificant). Your frustration is 
> valid, but so is theirs.
>
> As I have said many times now, adding stuff to Go comes with
>> a heavy price, it opens the door for all the people who have been whining
>> and complaining about Go for the past ten+ 

Re: [go-nuts] Re: Generics, please go away!

[Space A.]

Prime driver of Java's success were enterprises with huge amount of 
investments (money) into ecosystem along with all JSRs developed by 
companies and groups with J2EE becoming de-facto a standard for building 
enterprise applications. And all this was happening way before any generics.

среда, 23 декабря 2020 г. в 16:43:46 UTC+3, ren...@ix.netcom.com: 

> To add some weight to the pro generic side - from someone who doesn’t 
> necessarily think Go needs them - generics and more specifically the “Java 
> Collections” package was a prime driver in Java’s success. Moving highly 
> tuned and verified implementations into the core library removed a huge 
> burden on developers - allowing them to focus more time on application 
> structure/function rather than nuts and bolts - while gaining greater 
> “readability” as these apps used common/well known apis as a foundation. 
>
> On Dec 23, 2020, at 7:14 AM, 'Axel Wagner' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
> 
>
> On Wed, Dec 23, 2020 at 1:17 PM Martin Hanson  
> wrote:
>
>> @Ian, for more than 10 years we have managed nicely without generics.
>>
>
> Of course, this doesn't answer how we'd have managed *with* them.
>
> We did manage for decades without general purpose CPUs. We did manage for 
> several decades without functions, coroutines or hashtables. We did manage 
> for decades without portable programming languages or multi-tasking 
> operating systems. We managed for many decades without the internet or the 
> world wide web.
>
> In hindsight, though,  "we managed so long without them" doesn't appear to 
> be a very convincing argument to not have them today.
>  
>
>> So what is the real true-life problems that validates adding generics
>> to Go? I haven't seen a single example, seriously not one! I have only
>> seen useless examples like the one Ian gives in the talk, which of
>> course I know only serves as an example, but we need real life problems
>> to solve, not theoretical ones.
>>
>
> To me, this suggests that the issue isn't that you haven't seen enough 
> examples, but that you haven't found them convincing you that the benefits 
> outweigh the costs. Which is a completely valid position to take. 
> Obviously, lots of other people (at least some of which you, I think, 
> respect professionally) see that differently. Which is also completely 
> valid. So, confronted with that reality, there are many productive ways to 
> react. Some examples are
>
> • Try to engage in the design process to keep the cost down (i.e. suggest 
> simplifications to the generics design)
> • Try to engage in the design process to increase the benefits (i.e. 
> suggest improvements that increase its power)
> • Accept that it's possible for reasonable people to look at the same 
> problem and proposed solution and agree on what the costs and what the 
> benefits are, but weigh them differently, just as a matter of personal 
> taste or opinion - and thus agree to disagree
> • Try to change the other persons mind about what the costs or benefits 
> are and how much they weigh
>
> Now, that last one *can* be very productive. Especially early on in a 
> discussion, we tend to overlook hidden costs or surprising benefits and 
> having them pointed out can be really helpful. Personally, though, I must 
> say that the generics discussion has been going on for 10 years (and even 
> more, if we don't limit ourselves to Go) and I don't - personally - believe 
> that there is much hidden cost or surprising benefit left to be discovered. 
> And ISTM that swaying someone's mind on them will most likely take more 
> than just outright saying that you don't agree.
>
> So, I guess the question really is, what's the goal? Do you want to get 
> the best language? In that case, I'd personally suggest to focus on 
> improving the generics design. Or do you want to convince others that their 
> valuation of costs and benefits is inaccurate? In that case, I'd personally 
> suggest to try and find new costs or benefits - but keep in mind, that 10 
> years is a lot of time for a lot of them to already have been mentioned a 
> lot. Or do you just want to be heard as being in disagreement? That's also, 
> of course, valid.
>
> What I understand from all of this is that people who are pro-generics are
>> in reality really talking about something that is *nice to have*, not
>> something that is seriously needed and this is where I become really
>> frustrated!
>
>
> I understand this frustration. But it might help to keep in mind that 
> computers are simply nice to have in exactly the same way.
> And I think there's an opportunity to have empathy with people who *are* 
> in favor of generics. Because just like you are frustrated that generics 
> are just nice to have (i.e. you perceive their actual benefit as 
> insignificant), people on the other side of the aisle might be *just as* 
> frustrated by you, because generics are just slightly more complex (i.e. 
> they perceive 

Re: [go-nuts] Re: Generics, please go away!

[Space A.]

I didn't take part in few of the last surveys. However I filled that very 
last one and haven't seen any generics-related questions. It was also 
stated somewhere that some of them randomized? So I answered a lot of weird 
questions for anything, but language features. Anyways if Go is not 
poll-driven it doesn't make any sense and couldn't be an argument. Result 
could be different if people knew that decision will be made out of that 
survey results. Another thing is that after the years of this generics hype 
train without any alternative point of view, a lot of public just convinced 
that it's fine. 


среда, 23 декабря 2020 г. в 14:20:24 UTC+3, axel.wa...@googlemail.com: 

> On Wed, Dec 23, 2020 at 11:42 AM Kevin Chadwick  wrote:
>
>> I have to call it out here though as I see statistic abuse on the news 
>> every
>> day. Not to mention that asking the question encourages people to think of
>> something.
>>
>> Ignoring that encouragement in the question (and not remembering survey
>> structure). This would more accurately be described as 80% reported not 
>> needing
>> any new features and 15% reported needing Generics!
>>
>
> That re-framing is itself abuse of statistics. Because (as rightly pointed 
> out by Ian)
>
> > Of course this isn't definitive, since there was no clear way for people 
> they say that do not want generics.
>
> Unless there was a "I don't need any new features" checkbox, exactly 0% of 
> respondents reported not needing any new features.
> There not being such a checkbox might be considered a methodological flaw. 
> But luckily, the goal was neither to do science, nor to vote, so it doesn't 
> hugely matter.
>
> I think what how Ian phrased it, is unambiguously the most accurate 
> description: 25% of the survey takers answered that question and of those, 
> 79% mentioned generics. Any inaccuracies come from reading more meaning 
> into these numbers - as you tried when saying "80% reported not needing any 
> new features" or as would happen if Go *was* designed based on public polls 
> and these numbers would be used to say generics where desperately needed. 
> But it isn't and the survey isn't the (only) reason to include generics and 
> Ian was quite careful in pointing out the methodological flaws in trying to 
> interpret the numbers in any of these ways, so there is nothing to see here 
> :)
>  
>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/4ea1d4b4-6059-936e-5ad2-c7b4919eb369%40gmail.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/96a1297f-fbe6-4aac-b577-30d6028d23edn%40googlegroups.com.

Re: [go-nuts] Re: Generics, please go away!

[Space A.]

> Again, it bears repeating: "The Go designers where against generics" is 
historical fiction. "The Go team is succumbing to public pressure" is 
political fiction. Both are simply false. Anyone saying either of those 
either misunderstood something someone on the Go team said, or is repeating 
from someone else who misunderstood something. 

There is another possibility - you misunderstand something or someone and 
keep repeating that.

среда, 23 декабря 2020 г. в 01:40:37 UTC+3, axel.wa...@googlemail.com: 

> On Tue, Dec 22, 2020 at 11:09 PM Martin Hanson  
> wrote:
>
>> If you on the other hand is pro-generics to Go, then of course that is
>> your right.
>>
>
> Ian is on record, multiple times, as having argued in favor of generics in 
> Go long before its open source release and has since written many proposals 
> to add them - even before the Go community survey was a thing.
>
> Again, it bears repeating: "The Go designers where against generics" is 
> historical fiction. "The Go team is succumbing to public pressure" is 
> political fiction. Both are simply false. Anyone saying either of those 
> either misunderstood something someone on the Go team said, or is repeating 
> from someone else who misunderstood something.
>
> There are plenty of good reasons to criticize the addition of generics, 
> but neither of these is one.
>
> I for one doesn't hope that the future of Go is going to continue down
>> this road, with new proposals for change popping up on GitHub every
>> other day and surveys and possible outside pressure determining the
>> future of Go. I would very much like to know if this is going to be the
>> way it is.
>
> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/6452721608674913%40iva4-57c3b416b70c.qloud-c.yandex.net
>> .
>>
>

-- 
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/541a7371-7862-4e61-bfe9-0b7689916cc5n%40googlegroups.com.

Re: [go-nuts] Re: Generics, please go away!

[Space A.]

  > I have, plenty of times in the past, said myself that people who want 
generics should just use Java or C++. I'm not proud of saying that. It was 
a mistake. 

What if you actually were right? Have you ever been looking at it through 
"Clear is better than clever" prism? What if in 10 years you say: "Holy 
sh*t..." =) Sorry this might be my thought not yours.

I mean, what if lack of generics is actually one of the greatest feature of 
Go and we by all means should keep it like this. The fact is Go is great 
and successful without it, so do we really need to add anything? Because 
one of the key strengths is readability and clearness which you won't see 
anymore. And here you are, yet another boring language (I actually liked 
"write-only" term from one of comments above) which lacks so many features 
that others "had for years". Some ppl say "give it a chance", but giving 
something a chance means you can accept or deny if you don't like it. It's 
not a case because there is no magic switch you can turn on and off. There 
will be no way to reverse it.



вторник, 22 декабря 2020 г. в 16:07:20 UTC+3, axel.wa...@googlemail.com: 

> You are very welcome to voice your opinion. Including the opinion that 
> generics should not be added to Go.
> What you shouldn't do - and that's all I criticized - is to tell people 
> who disagree with you on that to go away.
>
> I also think it's not wrong to point out that claiming the original 
> designers of Go left out generics on purpose is, at least, distorting the 
> documented historical facts. Or to point out the contradiction in saying, 
> on the on hand, that we should listen to the original designers about what 
> does and does not belong into the design of Go and, on the other hand, 
> telling one of those exact designers that they are ruining the language.
>
> I'm genuinely sorry if you feel you can't voice your opinion based on my 
> message. But as best as I can tell, that is a reaction to a) me pointing 
> out exclusionary language or b) me pointing out logical problems with the 
> arguments presented.
> And if it's a) I must insist that the paradox of tolerance 
>  informs my decision 
> here - if I can only choose between people feeling excluded for wanting 
> generics or people feeling excluded because they can't make those people 
> feel excluded, I will have to choose the latter. And if it's b) I must 
> wonder why that isn't exactly the kind of technical, logical argument y'all 
> are looking for.
>
> To be clear, again, I have plenty of problems with generics in general and 
> with the current stage of the design in particular. For example, I am on 
> record as disagreeing with making usage of operators on type-arguments a 
> central part of the design - I feel that it creates most of the 
> complication in the design and I don't feel the benefit outweigh the cost. 
> But I understand and respect Ian's choice on that. It's a technical point 
> of contention and I politely disagree with him and live with that.
>
> I've also said, plenty of times, that I think the main use-case for 
> generics seem to be type-safe containers and that I feel the benefit of 
> type-safety there is overstated. And experimenting 
>  with the 
> current design for a while reinforced my impressions that some design 
> decisions (like not allowing additional type-parameters on methods) hamper 
> at least *some* of the non-container use-cases where Go could benefit from 
> more type-safety. However, again, I understand why those decisions where 
> made and I don't know of a way to solve these issues, so I'm left with 
> accepting that they might be the best possible solution, even if I don't 
> like them.
>
> As it currently stands, I'm undecided if I like generics in Go and 
> probably lean slightly against, given the current design (and would 
> probably lean in favor, with some changes). The decision is not up to me 
> though and I'm fine disagreeing with whatever decision is made - if it 
> comes to that. And living with it.
>
> I can't imagine any of these opinions about generics to earn me scorn or 
> reprimands based on the CoC. Because the issue isn't *disagreeing* with 
> generics or with voicing that opinion. It's *how* you voice it that matters 
> and if you do so in a respectful and technical manner.
>
> PS: Just make clear that I'm not claiming I'm perfect: I have, plenty of 
> times in the past, said myself that people who want generics should just 
> use Java or C++. I'm not proud of saying that. It was a mistake. I've done 
> plenty of those and I will make plenty of them in the future and I can just 
> hope I learn from them.
>
>

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

Re: [go-nuts] Re: Generics, please go away!

[Space A.]

Your message is perfect example of why most of the ppl who have their own 
different opinion and who have never been listened to or given that ability 
will just shut up, and stay away.

вторник, 22 декабря 2020 г. в 14:01:53 UTC+3, axel.wa...@googlemail.com: 

> On Tue, Dec 22, 2020 at 11:09 AM Martin Hanson  
> wrote:
>
>> It's a matter of understanding why generics was left out of Go from the
>> start, like classes was left out of Go. If we start adding stuff that
>> the original developers of Go left out by purpose
>
>
> That is some serious revisionism of the facts. Ian (who is spear-heading 
> the generics effort) is one of (if not *the*) first person to join Go's 
> development. And it has *always* been the communicated stance of the Go 
> team (including the original three people who've been there before him) 
> that generics would be nice to have, if they can figure out a way to fit 
> them in.
>
> I'm as skeptical about generics as the next guy. But this denial of 
> historical fact doesn't help anybody. Neither is exclusionary language like 
> talking about "true Gophers". Go is an inclusive project and wants everyone 
> to feel welcome - *obviously* that includes people who want generics in the 
> language. Please read - and keep to - the Go community Code of Conduct: 
> https://golang.org/conduct
>
>  
>
>> we're not understanding the design choices that went into Go, which is 
>> exactly
>> what makes Go unique!
>>
>
> Go is not a religion. Go is not something that was prophetized on stone 
> tablets and handed down from mysterious, otherworldly gods.
> It's a programming language and a software project. The people who came up 
> with it and designed it are alive and well and they explain their decisions 
> regularly and patiently. One of those people is Ian.
>
> I am comparatively late to the party with adopting Go, but even I feel 
> comfortable saying I understand the design choices that went into Go.
>  
>
>> If you want to add generics to Go, if you want to change how errors are
>> handled, if you want X, Y or Z feature that Java, C++, or some other
>> complex language has got, then go use that language! Why are you even
>> here!?
>>
>
> I said so above but it benefits from repitition: If you are someone who 
> wants the language to change, if you want generics, if you feel error 
> handling could be improved, "if you want X, Y or Z feature that Java, C++, 
> or some other complex language has got", you are welcome in our community. 
> Your viewpoint is valued. Your, Martin, viewpoint that generics *shouldn't* 
> be added to Go is valued as well.
>
> What isn't welcome is your attempt of alienating people with a different 
> viewpoint from yours and make them feel unwelcome. And if you continue to 
> insist on doing that, the community *will* ask you to leave.
>
> the people who designed Go, and we all know who they are
>
>
> No offense, but I do get the impression that you actually don't.
>  
>
>> If generics gets added to Go, we're opening a very dangerous door, and
>> it will be the downfall of Go because - and Robert Griesemer this is
>> especially addressed to you - what's next then?
>
>
> Just to be clear: On the one hand, you are trying to make an argument that 
> the original designers of Go are impossible to understand, their competency 
> transcends reason and they should be trusted to come up with the best 
> design for a language. And on the other hand, you are trying to explain one 
> of those original designers, who is currently working on adding generics, 
> that what they are doing is "the downfall of Go"? Think about it. That 
> should really cause you some cognitive dissonance.
>  
>
>> If generics gets added to Go, we're a big enough part of the community,
>> that passionately hate that, that we can manage to fork Go - which I
>> strongly believe will then be the right thing to do!
>>
>
> I can say, I would genuinely be happy if a fork of Go without generics 
> will be made and if people who feel they can't live with a language 
> containing them migrate to that fork. Just as I was genuinely happy about 
> Devuan being created by people who feel they can't live with an operating 
> system using systemd. The Debian project became better by that fork 
> existing and I suspect, the Go project would be better with such a fork.
>
> Because it would give relentlessly negative people a place to be in peace, 
> somewhere else.
>  
>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/5029411608631693%40iva7-919bb0034794.qloud-c.yandex.net
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving 

Re: [go-nuts] What are debian:buster-slim advantages vs alpine ones?

[Space A.]

We don't have a CGO in our project. We want libc and we value it because 
it's a gold standard which makes things stable and predictive. After all, 
container must just work, so we focus on our services other that testing 
and troubleshooting some side technology.

For issues you can take a look at their github and this will also give you 
some basic idea what process of mitigation is like. You will not find 
issues older than 2019 however. 



воскресенье, 20 декабря 2020 г. в 21:53:08 UTC+3, ntr...@gmail.com: 

> Most of the issues presented here are only relevant for CGO and other 
> programming languages, not Go.
>
> Also, could anyone share references about the security problems in Alpine? 
> I may say Windows is more secure and faster than Linux (or the opposite), 
> but without any evidence, it is just a conjecture.
>
> Some of the advantages from Alpine for me:
>
> * Image size. My internet connection is 1mbps (my country sucks) and I 
> usually have to share it with 15 other devices, so 100MB is a lot for me.
>
> * Simplicity. It is easier to become a US citizen than having your package 
> in the Debian stable branch. Haha just kidding, but it is pretty hard and a 
> lot of organizational complexity happens there [1]. If you use apt to 
> install some tools, you will get old releases (which is good for end-users 
> or servers, they are really well tested, but we are developers, and in 
> production you should probably use `scratch` with distributed tracing, 
> logging, etc...). Mirroring Debian repositories takes a lot of storage 
> space (the last time I did, it was ~250GB) because you have to download 
> every release and you need special tools [2] for that (you can setup a 
> proxy instead, but internet access is required most of the time), also the 
> mirror gets invalidated every in a while, so you are forced to update or 
> you will end up with a broken environment. For an Alpine mirror you only 
> need rsync and some options for excluding unneeded releases, so less 
> storage space is required (3.12 is <20GB). (Again, my country sucks, so I 
> need a mirror, or I will wait more than 30 minutes every time I have to 
> install some packages).
>
> * Consistency. If your build scripts work on Alpine, they will probably 
> work in any Unix (or at least Linux) environment.
>
> I don't consider deployment advantages because as I said, I prefer 
> deploying my binaries with `scratch`, but if I have to use `alpine`, I 
> would say:
>
> * Minimalism. It is not just only about numbers, but philosophy [3], 
> Alpine keeps everything as minimal as it can, packages are usually split 
> into `package`, `package-docs` (man pages), 
> `package-{bash,zsh,...}-completion`, so you get what you need, no more, no 
> less. 
>
> * Security. The attack surface is very small and C binaries are compiled 
> with some good security options.
>
> Don't take me wrong, I love Debian, it was my very first Linux 
> distribution. If CGO is a requirement and musl doesn't work out of the box, 
> you should choose `debian`, otherwise, I strongly recommend `alpine`.
>
> [1]: https://www.debian.org/releases/
> [2]: https://www.debian.org/mirror/ftpmirror
> [3]: https://wiki.alpinelinux.org/wiki/Alpine_Linux:Overview
>

-- 
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/3233217b-a8e2-4feb-b7de-018de68b2d07n%40googlegroups.com.

[go-nuts] Re: Generics, please go away!

[Space A.]

Unfortunately it was expected that creators of the language will not resist 
forever being under the pressure of masses most which do not even code in 
Go, or not use Go as the main language and just following patterns and 
shitty idioms they took elsewhere. Generics are bullshit crap in its 
essence. They either don't improve anything or overused (with some huge 
cost). I'm telling this as someone who had 15+ years in Java before moved 
to Go. I was literally happy when I found that Go has almost everything 
which is good about programming and almost nothing bad. And I knew that it 
will start degrading at some point. I just keep some hopes that community 
will fork the language after this "Cyberpunk" releases. Rephrasing "no is 
temporary, yes is forever": good Go is temporary.




воскресенье, 20 декабря 2020 г. в 22:38:54 UTC+3, Martin Hanson: 

> I think people who want generics added to Go should go and program in Java 
> or C++. 
>
> Adding generics to Go will ruin the beautiful simplicity of the language 
> and I haven't found a single example in which adding generics to Go pays 
> off. 
>
> Even with the examples of having two almost identical functions reverse 
> some list, one of ints and one of strings, seriously!? We already have tons 
> and tons of open source reusable code that covers all use cases which 
> people complain about. 
>
> Go was designed without generics purposefully from the start and Go is 
> fine just the way it is. 
>
> Adding generics means that we're opening the door to the beginning of 
> bloating Go with all the crap that Java, C++ and all the other complex 
> languages has gotten over the years, and Go was designed specifically 
> without that clutter. So we add generics, then what? Classes? 
>
> Adding generics to Go ruins that beautiful simplicity that went into the 
> design and the added complexity just isn't worth it! The standard library 
> have managed just fine without generics and so have we! 
>

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

Re: [go-nuts] What are debian:buster-slim advantages vs alpine ones?

[Space A.]

Hi Constantine,

In our project we'd chosen debian-slim images vs alpine few years ago due 
to a number of reasons, if I recall arguments were like:

1. presence of libc
2. bugs and performance issues of alpine
3. security issues of alpine 
4. debian is more suitable for testing with huge amount of tools available 
out of the box, if needed


After all, talking about saving few tens of megs of hdd space per image 
(it's the main reason for ppl selecting alpine) is ridiculous nowadays IMO.



среда, 16 декабря 2020 г. в 20:10:49 UTC+3, Constantine Vassilev: 

> What about the size of images? For pure Golang project what are the 
> advantages of glibc?
>
> For a project I have to present pro and cons before the team to decide.
>
> On Tuesday, December 15, 2020 at 6:03:29 PM UTC-8 amits...@gmail.com 
> wrote:
>
>>
>>
>> On Wed, 16 Dec 2020, 12:38 pm Constantine Vassilev,  
>> wrote:
>>
>>> All examples in Google Cloud Run for building
>>> Golang Docker images are based on Debian.
>>>
>>> FROM golang:alpine AS builder
>>> ...
>>> FROM debian:buster-slim
>>> ...
>>>
>>> What are debian:buster-slim  advantages vs alpine ones?
>>>
>>
>> Besides the size of the images, one key difference would be the 
>> underlying C library - Debian would be glibc and Alpine would be libmusl
>>
>> So advantages would be if knowing that libc is available.
>>
>>> -- 
>>> 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/2433a1dd-c3ea-4c5c-9f6e-d1595cef99f9n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/golang-nuts/2433a1dd-c3ea-4c5c-9f6e-d1595cef99f9n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
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/9f0bd697-286f-455a-afef-4a49e98fea80n%40googlegroups.com.

[go-nuts] Re: Any recommendation for structured logging library in Golang?

[Space A.]

If you want to go for structured and layered logging in JSON, consider 
https://github.com/francoispqt/onelog


четверг, 19 ноября 2020 г. в 12:14:21 UTC+3, Denis Cheremisov: 

> Zerolog does the trick, need a bit of setup though for what you want
>
> среда, 18 ноября 2020 г. в 07:21:48 UTC+3, ChrisLu: 
>
>> I am considering moving from glog to structured logging. I tried logrus, 
>> go-kit, uber/zap, but could not find one good fit. In short, this is the 
>> desired format:
>>
>> [info][timestamp] [filename:line_number] message k1=v1 k2=v2 ...
>>
>> It shows the correct file name(need to pop out a few call stacks) and 
>> line number in a customizable format, not as key-value pair for each line 
>> which is just too verbose to have the extra "time=" "file=".
>>
>> Please let me know the one you actually use.
>>
>>
>> Thanks!
>> Chris
>> -
>> https://github.com/chrislusf/seaweedfs
>>
>

-- 
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/0050ca29-a406-4d30-b375-b5d3dd871dban%40googlegroups.com.

Re: [go-nuts] Stop triggering firewall on Windows? Preset build path?

[Space A.]

Just was going to say that =)

суббота, 7 ноября 2020 г. в 23:01:17 UTC+3, Egon: 

> If you use `127.0.0.1:0` as your listening address then the firewall won't 
> trigger as well.
>
> On Saturday, 7 November 2020 at 15:20:06 UTC+2 Aleistar Markóczy wrote:
>
>> I may not be "using go run as a development tool" (which I would deem a 
>> perfectly fine reason to use "go run", I mean what else would you use it 
>> for, maybe to run on production? ;-) ) but the same happens when running go 
>> test to run tests while creating a server to run the tests on.
>>
>> The trick of opening the port works perfectly file, thanks! Just open the 
>> windows Firewall Settings > Advanced Settings > Inbound Rules > New Rule > 
>> By Port.
>>
>> On Wednesday, 11 February 2015 at 15:38:53 UTC+1 ni...@craig-wood.com 
>> wrote:
>>
>>> On 11/02/15 10:13, Mateusz Czapliński wrote: 
>>> > Or, I believe "go build && myappname.exe" (as mentioned by Egon too) 
>>> is 
>>> > on par with go install, with the small difference between the two 
>>> (i.e. 
>>> > location of the resulting executable) left up to personal 
>>> > choice/preference/needs. 
>>>
>>> If you have a big project you'll notice the difference in speed between 
>>> go build and go install. It is especially noticeable if you have 
>>> modified code in a package which you are not typing go build for - that 
>>> has to be rebuilt every time. 
>>>
>>> In my 25,000 line project split over 50+ files it takes about 2 seconds 
>>> for a cold build, but only 0.6s for a go install after that cold build. 
>>> go install speeds up subsequent go builds. 
>>>
>>> .../src/github.com/ncw/myproject$ rm -rf 
>>> ~/go/pkg/linux_amd64/github.com/ncw/myproject 
>>> .../src/github.com/ncw/myproject$ time go build 
>>>
>>> real 0m1.972s 
>>> user 0m1.796s 
>>> sys 0m0.237s 
>>>
>>> .../src/github.com/ncw/myproject$ time go build 
>>>
>>> real 0m2.004s 
>>> user 0m1.797s 
>>> sys 0m0.255s 
>>>
>>> .../src/github.com/ncw/myproject$ time go install 
>>>
>>> real 0m1.955s 
>>> user 0m1.809s 
>>> sys 0m0.210s 
>>>
>>> .../src/github.com/ncw/myproject$ time go install 
>>>
>>> real 0m0.614s 
>>> user 0m0.531s 
>>> sys 0m0.085s 
>>>
>>> .../src/github.com/ncw/myproject$ time go build 
>>>
>>> real 0m0.960s 
>>> user 0m0.864s 
>>> sys 0m0.080s 
>>>
>>> -- 
>>> Nick Craig-Wood  -- http://www.craig-wood.com/nick 
>>>
>>

-- 
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/f5b6c4d3-9c7b-4b68-a2ec-c19c8b95e7b8n%40googlegroups.com.

[go-nuts] Re: Licence details of github.com/golang/sync

[Space A.]

Are you creating your own programming language and tools and going to 
release it under own license terms? If not, and you're using this lib only 
to program your projects, there are no restrictions.

четверг, 29 октября 2020 г. в 16:52:17 UTC+3, Denis Cheremisov: 

> Hi!
> At my job we found these additional patents limitatations 
> https://github.com/golang/sync/blob/master/PATENTS
> They makes us impossible to use errgroup (which is, to say, turned to have 
> pretty poor choice of WithContext signature, so our one is different), so 
> we have our custom implementation of it with additonal functionality 
> (errors collector, concurrency limitation), but it is derived from the 
> original implementation.
>
> I guess the repository should be called "github.com/google/sync" after 
> that. Anyway, our product's proprietary licence makes it impossible to use 
> our derived implementation. Is there a way to overcome this somehow? The 
> problem is my own implementation would be really close to this and thus 
> prone to a sue.
>

-- 
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/08842c88-f4c0-44d5-89aa-c1c624c832bfn%40googlegroups.com.

[go-nuts] Re: Go is easy to lean. But other languages are hard to forget

[Space A.]

You won't write good idiomatic Go just after 1 day of learning it. Even 
after a week.


воскресенье, 4 октября 2020 г. в 23:25:19 UTC+3, Amnon: 

> Go is a beautifully simple language. It is easy to learn.
> Most programmers can learn to write working production code within a day.
>
> But learning Go is the easy thing. It is much much harder to liberate 
> yourself
> from the conceptual baggage that you have inherited from languages in your 
> past.
> Every programmer carries scars from the sharp corners of previous 
> languages,
> and these scars continue to infect the code they write today.
> It takes many months of immersion in idiomatic Go for these scars to have 
> a chance to heal. Sometimes years. And some programmers never manage 
> to escape the traumas and convoluted rituals of the past. And they are 
> doomed to continue
> writing their former language in Go syntax, for the rest of their careers.
>
> So learning Go is easy. But exorcising the ghosts of former languages 
> can be very very hard.
>

-- 
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/5690ec8b-4c52-42d1-9c2d-bed367bf6a42n%40googlegroups.com.

[go-nuts] Re: go modules and local packages

[Space A.]

I had the same situation and this worked perfectly:

replace mylib => ../mylib

If it doesn't - check paths, name of the "mylib" module, etc



суббота, 8 августа 2020 г. в 21:20:56 UTC+3, Sankar: 

> Hi
>
> I have a monolithic source repository that is NOT in git, mercurial etc.
>
> The directory structure is:
>
> root
> |
> |--- mylib
> | | --- mylib.go
> | | --- go.mod
> |--- svc1
> |   | --- go.mod
> |   | --- cmd
> | |  svc1.go
> |--- svc2
> |   | --- go.mod
> |   | --- cmd
> | |  svc2.go
>
> Here there is a `mylib` which is a common library. `svc1` and `svc2` are 
> two golang http servers that come with their own `go.mod` files. Now I want 
> to import the `mylib` in the `svc1` and `svc2` sources and the go.mod files.
>
> Can someone tell me how to achieve this ? I can modify the go.mod of 
> `mylib` to anything but cannot publish the sources to a VCS.
>
> I tried adding the following in the go.mod files of svc1 and svc2 but it 
> did not work.
> replace (
> my.lib latest => ../mylib latest
> )
>
> Any other suggestions to get this working ? Thanks.
>

-- 
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/2b4b34b3-3555-4b89-8e5e-b63035a9f238n%40googlegroups.com.

Re: [go-nuts] composite literal uses unkeyed fields

[Space A.]

I'm using unkeyed fields for the opposite reason: I don't want code to 
compile when I add new fields to the struct, unless this is reflected at 
the other end. For example, I found it very useful sometimes, to pass a 
long list of arguments to the function through a struct. The same would 
happen if I pass arguments directly and change signature of the function by 
adding arguments, so the code won't compile if this function is still being 
called with lesser number of arguments. But it could compile incorrectly, 
if I just change the order of the arguments of the same type.


On Thursday, January 7, 2016 at 6:33:20 PM UTC+3, Rob 'Commander' Pike 
wrote:
>
> The argument for the complaint is that keyed composite literals are more 
> future-proof. If you later change the layout of s, the code will fail to 
> compile if the keys no longer work, but an unkeyed literal may compile 
> incorrectly. In your example, if you swapped a and b in s, the first 
> assignment of z would set 1 to b and 2 to a.
>
> It also affects guarantees of compatibility. See 
> https://golang.org/doc/go1compat.
>
> -rob
>
>
> On Thu, Jan 7, 2016 at 2:21 AM, Tamás Gulácsi  > wrote:
>
>> Add keys - for
>> type s struct{a,b int}
>> Instead of z :=s{1,2}
>> Use z :=s{a:1,b:2}
>>
>> --
>> 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 golan...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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/0cb8f3c8-9551-4965-b427-f3a74f088ac2o%40googlegroups.com.

Re: [go-nuts] Re: political fundraising on golang.org!

[Space A.]

> To people who object to the banner as too focused on the United States: 
> Google and Go both started here, nearly all of the Go team is here, a 
> substantial number of Go community members live here, and many others 
> travel here for conferences or other reasons. The situation here affects 
> gophers worldwide.
>
>  
Are you saying you don't care about the rest of the World? This "situation" 
does not affect in any way many many gophers which have to deal with much 
more serious problems than you could imagine, on a daily basis. There are a 
lot of projects originating not from US, who are not trying to get you 
attention (and money) by putting on top political topics which they think 
are important and "affecting" everyone.

That's pretty much easy to make this banner appear based on location. But 
if you insist, I can for sure update ABP filters with a couple of clicks. 
Never though I would have to do this on programming language main page.


 

-- 
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/0e9797d6-c7d4-429d-bf1e-592666b75868o%40googlegroups.com.

Re: [go-nuts] Re: political fundraising on golang.org!

[Space A.]

Because there are hundreds or thousands of initiatives to support suffering 
and dying people in African, Asian, Eastern European, and what else 
countries that will never be supported by top banner at golang.org.

On Monday, June 15, 2020 at 4:33:05 PM UTC+3, Sam Whited wrote:
>
> Why is it disrespectful to the rest of the world? In what way does 
> supporting the Black Lives Matter movement and an important not-for- 
> profit diminish from other problems that also need solving? 
>
> One of my neighbors recently put it this way: would you walk up to 
> someone at a breast cancer awareness march and ask "what's wrong with 
> you, don't you know that all cancers matter?!". Of course you wouldn't. 
> So ask yourself why people are so willing to do that with this issue in 
> particular. 
>
> —Sam 
>
> On Mon, Jun 15, 2020, at 08:58, Space A. wrote: 
> > Agree with Peter. It's not the right place and time and disrespectful 
> > for the rest of the World. You don't even imagine what problems, 
> > social or political, people who live far away from US face each and 
> > every day. 
>

-- 
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/0d083f13-9977-4da5-8ee9-8854c079ba2eo%40googlegroups.com.

[go-nuts] Re: political fundraising on golang.org!

[Space A.]

Agree with Peter. It's not the right place and time and disrespectful for 
the rest of the World. You don't even imagine what problems, social or 
political, people who live far away from US face each and every day.


On Sunday, June 14, 2020 at 4:36:38 PM UTC+3, peterGo wrote:
>
> Recently, a political message with a fundraising link appeared as a banner 
> atop golang.org websites: https://golang.org/, https://pkg.go.dev/.
>
> content/static: add Black Lives Matter banner to top of site
> https://go-review.googlesource.com/c/website/+/237589
>
> 
> Black Lives Matter.
> https://support.eji.org/give/153413/#!/donation/checkout;
>target="_blank"
>rel="noopener">Support the Equal Justice Initiative.
> 
>
> How was this decision made?
>
> Go is a programming language. For political fundraising use personal 
> Twitter and Facebook accounts. 
>
> Peter
>

-- 
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/132c4526-4b53-4c09-847a-4b950672736bo%40googlegroups.com.

[go-nuts] Re: How to correctly json.Unmarshal struct whose embedded structs define UnmarshalJSON

[Space A.]

1. I think it's not correct to use terms "parent" and "child", as Go is not 
an OOP language.
2. Please note that what you call a Child is actually a Parent, and vice 
versa. This puts a lot of confusion.
3. Embedding struct will get methods of embedded (depending on whether 
they've been defined for value or pointer receivers and so on), so if I get 
your question right, then when you "inherit" these methods and you don't 
want this to happen, either not embed (put in a field instead), or override 
this method, or make this method be more universal for different cases.


On Tuesday, December 31, 2019 at 1:21:07 PM UTC+3, Glen Huang wrote:
>
> I want to unmarshal a struct that contains embedded structs:
>
> type Parent struct {
>  Child
>  P int 
> }
>
>
> type Child struct {
>  Grandchild
>  C int
> }
>
>
> type Grandchild struct {
>  G int
> }
>
> The problem is that Grandchild defines its own UnmarshalJSON method, and 
> that means Parent inherits it and breaks json.Unmarshal.
>
> I wonder if it's possible to correctly unmarshal Parent without overriding 
> UnmarshalJSON for every member in the embedding chain? It's correctly the 
> only way I know that can fix the issue, but it's very cumbersome, and there 
> are cases where I only have control over Parent, but not Child and 
> Grandchild,
>
> Thanks. 
>

-- 
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/e48b8861-045c-4b78-81e6-931174363be0%40googlegroups.com.

[go-nuts] Re: Why Iran is banned by Google?

[Space A.]

It's very interesting fact to know for everyone in this group including 
Google employees, that seems only Google just don't care and bans 
educational/scientific resources for other countries' ordinary citizens (of 
course govs and mils are aware of how to use VPN to access golang.org).


On Wednesday, July 18, 2018 at 8:54:44 AM UTC+3, Kaveh Shahbazian wrote:
>
> FYI GitHub, GitLab, all things Microsoft (.NET Framework, VSCode, etc), 
> Amazon Instances etc, etc are perfectly reachable inside Iran - whatever.
>
>
>
>
>
>

-- 
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/3575b629-150c-4c9c-b8ff-a3b5cf9b6d58%40googlegroups.com.

[go-nuts] Re: [ANN] Go Server Pages

[Space A.]

Interesting, but you know what, when I read that web server name is Apache* 
in 2019, I don't read any further.



On Tuesday, October 8, 2019 at 8:16:09 PM UTC+3, Scott Pakin wrote:
>
> I'm excited to announce the initial release of
>
> Go Server Pages
>
> Go Server Pages is an Apache module that lets you embed Go code within a 
> Web page.  The Go code gets executed dynamically server-side.  Here's a 
> quick example:
>
> 
> 
>   
> Test of Go Server Pages
> 
>   
>
>   
> You should https://gosp.pakin.org/;> strings.ToUpper("try Go Server Pages today") ?>!
>   
> 
>
>
> When a page like that is served over the network, the client sees the Go 
> code replaced with its output:
>
> …
>
> You should https://gosp.pakin.org/;>TRY GO SERVER PAGES 
> TODAY!
>
> …
>
> If you're familiar with PHP, it's a lot like that but using Go as the 
> programming language and with more thought given to security in the 
> implementation.  Here's where to go for documentation and downloads:
>
> Home page: https://gosp.pakin.org/
> GitHub repo: https://github.com/spakin/gosp
>
>
> Enjoy!
>
> — Scott
>
>

-- 
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/0cb4f53b-bce1-40f3-832c-840f08885be9%40googlegroups.com.

Re: [go-nuts] Golang library for - ORM & Schema Migration

[Space A.]

ORM is a tool. It's not good or bad. Every tool, every language and
everything has limits. If you like spending time on writing and debugging
raw SQL - go ahead. The difference and very obvious in this discussion, is
that those who are not against ORM not trying to convince other party to
only use this and that and nothing else.


вс, 29 сент. 2019 г. в 05:19, Marcin Romaszewicz :

>
> I've used naked SQL, and ORMs (Django in Python, Hibernate and EBean in
> Java, GORM in Go) for years, and I've noticed the following:
>
> 1) It's really easy to write very inefficient queries in an ORM. If you
> have a very simple 1:1 mapping between tables and objects, it's fast,
> efficient, easy to use, and by all means, use the ORM. However, once you
> start doing tricker things, like references to other objects (aka, foreign
> row constraints on other tables), or array type fields, things get really
> tricky.
>
> 2) A database abstraction layer is nice, because while SQL is standard,
> every dang database extends SQL in its own way that's usually not
> compatible with others. For example, Postgres supports array columns. MySQL
> does not. These two are both very popular. If you have an object which
> you're storing in a table, your approach in each DB will be drastically
> different. In Postgres, you just write the array into a column. In MySQL,
> you have to decompose to First Normal Form, meaning you create a table for
> the array column, and have some sort of array/table -> PK mapping. Or, you
> give up on any kind of easy array searching, and just marshal your array to
> JSON or whatever, and throw it in a CLOB.
>
> 3) An ORM ties your hands to using SQL in whatever approach it presents,
> so you frequently do naked SQL outside of the ORM, particularly if you want
> to use something to speed up a query which is very difficult for an ORM to
> express, such as Window Functions in Postgres.
>
> Given that no two SQL engines speak the same dialect, and ORMs don't
> understand intent, you're basically always debugging. If your object model
> is simple, an ORM saves work, if it's complex, I'd argue it's more work. If
> you have to support multiple DB's, eg, Postgres for production. SQLite for
> unit tests, you need a query builder since their syntax is incompatible, or
> stick to a compatible subset. SQL is a mess, ORM or no ORM, and in any
> language. Just use what works for you, and reevaluate if it starts to cause
> problems.
>
> I've been responsible for internet facing services backed by databases for
> quite a few years now, could rant about this for a long time. My current
> system, and the best one yet, having learned from past mistakes, uses
> something like Liquibase for schema management (I wrote it in Go, I'll be
> open sourcing it at some point, once it's battle hardened), and naked SQL
> queries, with some simple wrappers to hide nullable columns, since the
> zerovalue in go is simpler to work with than optionals.
>
> -- Marcin
>
>
>
> On Sat, Sep 28, 2019 at 6:12 PM Robert Engels 
> wrote:
>
>> ORM is object relational mapping. Go is only pseudo object oriented. I
>> will say again that complex object graphs and persistence is very hard
>> without an ORM or a LOT of custom code.
>>
>> Since Go does not have runtime compilation a true (or easy anyway) ORM in
>> Go requires code generation.
>>
>> On Sep 28, 2019, at 9:32 AM, Rodolfo  wrote:
>>
>> "First, nobody thinks that knowing ORM's query language absolves one from
>> knowing SQL."
>>
>> Speak for yourself.
>>
>> If you a hard spring boot user you can get into this problem.
>>
>> Example:
>>
>> findAll = select * from entity
>>
>> This is have nothing with SQL.
>>
>> findAllBySomeProperty = select * from entity where property = ?
>>
>> This is have nothing with SQL.
>>
>> Please, do not be rude, be honest.
>>
>> Em sáb, 28 de set de 2019 00:49,  escreveu:
>>
>>> First, nobody thinks that knowing ORM's query language absolves one from
>>> knowing SQL.
>>>
>>> But the main issue is that Go SQL interface SUCKS. It's verbose, hard to
>>> use and is difficult to integrate with additional tooling (try adding
>>> generic tracing support, I dare you!). So often your SQL code is hidden in
>>> reams of wrapper code that sets arguments and reads the results.
>>>
>>> So even simple ORMs that allow mapping of result sets to objects help to
>>> reduce boilerplate clutter. More advanced ORMs also offer simple type safe
>>> queries: https://github.com/go-reform/reform
>>>
>>> It's still nowhere close to LINQ for C# or http://www.querydsl.com/ for
>>> Java, but it's getting there.
>>>
>>> On Friday, September 27, 2019 at 3:34:59 AM UTC-7, Dimas Prawira wrote:

 Many Gophers don't like ORM as :
 1. ORM introduce an additional layer of abstraction that doesn't
 accomplish anything.
 2. SQL syntax is more or less the same for every database.
 3. If you learn an ORM in Java, you will only ever able to use that
 ORM knowledge in Java. If you learn 

Re: [go-nuts] Golang library for - ORM & Schema Migration

[Space A.]

Absolutely, plus ORM usually offers a convenient way to run raw SQL 
queries, if you need it.



On Saturday, September 28, 2019 at 7:50:22 AM UTC+3, alex.b...@gmail.com 
wrote:
>
> First, nobody thinks that knowing ORM's query language absolves one from 
> knowing SQL.
>
> But the main issue is that Go SQL interface SUCKS. It's verbose, hard to 
> use and is difficult to integrate with additional tooling (try adding 
> generic tracing support, I dare you!). So often your SQL code is hidden in 
> reams of wrapper code that sets arguments and reads the results.
>
> So even simple ORMs that allow mapping of result sets to objects help to 
> reduce boilerplate clutter. More advanced ORMs also offer simple type safe 
> queries: https://github.com/go-reform/reform
>
> It's still nowhere close to LINQ for C# or http://www.querydsl.com/ for 
> Java, but it's getting there.
>
> On Friday, September 27, 2019 at 3:34:59 AM UTC-7, Dimas Prawira wrote:
>>
>> Many Gophers don't like ORM as :
>> 1. ORM introduce an additional layer of abstraction that doesn't 
>> accomplish anything.
>> 2. SQL syntax is more or less the same for every database.
>> 3. If you learn an ORM in Java, you will only ever able to use that ORM 
>> knowledge in Java. If you learn SQL, you can use that SQL with almost 
>> _exactly the same_ with any other database, and in any programming language.
>> 4. ORMs don't save you any time. The number of "lines" of code for an 
>> ORM will be more or less the same as the equivalent logic done in SQL.
>>
>> But if still need to use ORM for any reasons, then you can try GORM 
>> https://gorm.io/
>>
>> cheers
>>
>> On Fri, Sep 27, 2019 at 4:20 AM b ram  wrote:
>>
>>> Hi,
>>>
>>> Can you pls suggest libs for  ORM & Schema Migration.
>>>
>>> Thanks.
>>>
>>> -- 
>>> 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 golan...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/CAB9V516cRxPc8xuQcXQyBGXZWenv0o9ned%2BFDq2WmXyhBNm2Sg%40mail.gmail.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/537ad21d-4f85-4a23-bf45-89a647ac527a%40googlegroups.com.

Re: [go-nuts] Golang library for - ORM & Schema Migration

[Space A.]

Many gophers like ORM.

ORM is a tool and as any other tool it does save the time when used in a
right way in a right place. But you need to learn how to use it.

пт, 27 сент. 2019 г. в 13:35, Dimas Prawira :

> Many Gophers don't like ORM as :
> 1. ORM introduce an additional layer of abstraction that doesn't
> accomplish anything.
> 2. SQL syntax is more or less the same for every database.
> 3. If you learn an ORM in Java, you will only ever able to use that ORM
> knowledge in Java. If you learn SQL, you can use that SQL with almost
> _exactly the same_ with any other database, and in any programming language.
> 4. ORMs don't save you any time. The number of "lines" of code for an ORM
> will be more or less the same as the equivalent logic done in SQL.
>
> But if still need to use ORM for any reasons, then you can try GORM
> https://gorm.io/
>
> cheers
>
> On Fri, Sep 27, 2019 at 4:20 AM b ram  wrote:
>
>> Hi,
>>
>> Can you pls suggest libs for  ORM & Schema Migration.
>>
>> Thanks.
>>
>> --
>> 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/CAB9V516cRxPc8xuQcXQyBGXZWenv0o9ned%2BFDq2WmXyhBNm2Sg%40mail.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/m-h6sDAX_MA/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CA%2Bp%2BMUeNpeCo_RRfb%2BQRVK%3DHHNhfY4_WYo12QeV8AQOfG%2B2KvA%40mail.gmail.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CADKwOTcM6XK%3Dzzc2_4fBAUc2Uunby3AR%2BZgTHtc%3DjU-S74%3D9Wg%40mail.gmail.com.

[go-nuts] Re: Golang library for - ORM & Schema Migration

[Space A.]

gorm.io


On Friday, September 27, 2019 at 12:20:54 AM UTC+3, bram wrote:
>
> Hi,
>
> Can you pls suggest libs for  ORM & Schema Migration.
>
> Thanks.
>

-- 
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/cfcb9ef8-c1ec-44ec-abb0-f7a4e74334c2%40googlegroups.com.

Re: [go-nuts] nested or sub template by variable

[Space A.]

Just use {{if}}...{{elseif}} statements that will check .MainContent 
equality to specific value and will invoke specific {{template ...}}




On Wednesday, September 11, 2019 at 3:40:22 PM UTC+3, dun...@gmail.com 
wrote:
>
>
>
> On Tuesday, April 17, 2012 at 2:52:03 PM UTC+1, Rob 'Commander' Pike wrote:
>>
>> You can't, for safety reasons in html/template. The text/template
>> package has the same property so the packages are consistent.
>>
>> The examples in the documentation for text/template show how the same
>> effect can be achieved safely.
>>
>
> What's unsafe about the code above?
>
> The basic issue I'm trying to solve is that I want to have a general 
> "layout" framework for web pages, in which I have a navbar at the top, a 
> navbar at the side, and content in the mail part.  The natural way to do 
> this would be to have a template that looks like this:
>
> {{define "page"}}
> {{template "navbarTop" .NavbarTopArgs}}
> {{template "navbarLeft" .NavbarLeftArgs}}
> {{template .MainContent .MainContentArgs}}
> {{end}}
>
> Then you define templates for the different main pages, and call the 
> "page" template at the top saying which of the templates to render.
>
> Looking around, there are basically three alternate solutions to this 
> problem, none of which are very satisfying:
>
> * Solution 1: Multiple parsed templates
>
> In this one, you define your main template like this:
>
> {{define "page"}}
> {{template "navbarTop" .NavbarTopArgs}}
> {{template "navbarLeft" .NavbarLeftArgs}}
> {{template "content" .MainContentArgs}}
> {{end}}
>
> Then for each "main content" page, you define a separate file that 
> contains a "content" template.
>
> But this means having a fully separate template variable, and all the 
> template code, for each different view of the webpage.  This seems really 
> repetitive an inefficient.
>
> Examples suggesting this:
>
>
> https://blog.rubylearning.com/go-web-programming-nesting-templates-f008418c6cc8
>
>
> https://hackernoon.com/golang-template-2-template-composition-and-how-to-organize-template-files-4cb40bcdf8f6
>
> * Solution 2: Invert the nesting
>
> In this option, you have each "main content" template manually include the 
> navbars, thus:
>
> {{define "MainContentAbout"}}
> {{template "navbarTop" .NavbarTopArgs}}
> {{template "navbarLeft" .NavbarLeftArgs}}
> ... content of 'about' page...
> {{end}}
>
> This again is repetitive -- each page has to include the navbars, and if I 
> (say) wanted to add a footer, I'd have to manually go and add it to each of 
> my content pages; and I might make a mistake and miss some.
>
> Examples suggesting this:
>
>
> https://levelup.gitconnected.com/using-go-templates-for-effective-web-development-f7df10b0e4a0
>
> The problem with both #1 and #2 is that they're violating the Don't Repeat 
> Yourself principle.
>
> * Solution 3: Work around the limitation with functions
>
> In this case, you define a function that will do the work of 
> programmatically nesting templates for you, like this:
>
> {{define "page"}}
> {{template "navbarTop" .NavbarTopArgs}}
> {{template "navbarLeft" .NavbarLeftArgs}}
> {{content .MainContentTemplate .MainContentArgs}}
> {{end}}
>
> And then implementing a function that looks like this:
>
> funcs := template.FuncMap{
> "content": func(t string, arg interface{}) (template.HTML, error) {
> buf := bytes.NewBuffer(nil)
> mtmpl, err := template.ParseFiles("templates/study.html.tmpl")
> if err == nil {
> err = mtmpl.ExecuteTemplate(w, t, arg)
> }
> return template.HTML(buf.String()), err
> },
> }
>
> This has the benefit of being able to make our layout fully 
> parameterisable.  But it means having this weird structure where we go into 
> a template, go out into go, and go back into a *different* template.
>
> Examples of people recommending this approach:
>
> https://github.com/spbooks/go1/blob/master/chapter4/3_layouts/template.go
>
> It seems like it would be much better to simply incorporate #3 into the 
> language itself.
>
>

-- 
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/efcad4f0-8296-4df1-9e60-07f677b2d253%40googlegroups.com.

Re: [go-nuts] Re: About the Google logo on the new Go website

[Space A.]

Unless there are financial reports published for passed years, my personal 
opinion is that accurate term could be "use of official position or office 
for personal gain". Quite common thing to such a big companies, tbh.
Oh, and don't forget "If you are independent artist tried to make something 
for community - your problem, sincerely yours, Google"


On Friday, July 19, 2019 at 8:35:53 AM UTC+3, andrey mirtchovski wrote:
>
> what you're doing has a term: character assassination. 
>
> please take it elsewhere. there are plenty of forums to air your 
> grievances. 
>
> On Thu, Jul 18, 2019 at 11:31 PM Space A.  > wrote: 
> > 
> > Another funny thing and I'm glad that you mentioned, is that "Woman Who 
> Go" and other known "non-google" initiatives, as you said, were founded or 
> co-founded by "developer advocate" Ashley McNamara. I don't know what kind 
> of contract or collaboration, or relations she had with Google or Google 
> employees, but she was quite "official" I would say, on all these 
> conferences. Now, she works for Microsoft. She also created and promoted 
> own printshop with Go-related merch with help of official Go community 
> channels: conferences, social networks, slack, etc. So, the interesting 
> thing is that in the post in Go blog it was claimed that 100% of money from 
> new "official" store will go to so-called non-profit org "GoBridge": 
> https://github.com/gobridge/about-us 
> > which is also seems to be founded or co-founded by her, along with other 
> existing Google and (perhaps some of the) ex-Google employees: 
> https://github.com/gobridge/about-us#leadership-team 
> > Ashley McNamara name there on the first place. 
> > 
> > You can Google a lot with her name and "GoBridge", "Woman Who Go" and 
> other keywords. For example here is her Patreon where she collects 
> donations for Go-related artworks, and also mentions that "Woman Who Go" 
> and "GoBridge" are being merged: 
> https://www.patreon.com/posts/women-who-go-24864094 
> > 
> > So all money will still go to that same project but now with promotion 
> made on very top level, in official Go Programming Language blog. Even if 
> that org is true and registered "non-profit" org, I suspect it still pays 
> salaries and give contracts to sub-contractors. I tried to find any 
> financial reports and proofs or evidence of real actions taken, but all I 
> found is some very general stuff. At least it very suspicious. I don't 
> believe that Google can't fund such a non-profit initiative without 
> affecting true artists. 
> > 
> > And apparently, very unlikely, that you paid a cent to any independent 
> artist over that years. 
> > 
> > 
> > 
> > On Friday, July 19, 2019 at 6:13:26 AM UTC+3, andrey mirtchovski wrote: 
> >> 
> >> really? throughout the years (and I've been here since the beginning) 
> >> i have spent infinitely more on non-google "go" merch than on google 
> >> go merch: stickers, t-shirts, campaigns supporting women who code, 
> >> etc, etc. 
> >> 
> >> come on. get off your high horse. 
> > 
> > -- 
> > 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 golan...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/39fb6e76-6acb-4470-b249-bcb202580d45%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c7e6bcea-659a-4d3e-8753-07757b797b62%40googlegroups.com.

Re: [go-nuts] Re: About the Google logo on the new Go website

[Space A.]

Another funny thing and I'm glad that you mentioned, is that "Woman Who Go" 
and other known "non-google" initiatives, as you said, were founded or 
co-founded by "developer advocate" Ashley McNamara. I don't know what kind 
of contract or collaboration, or relations she had with Google or Google 
employees, but she was quite "official" I would say, on all these 
conferences. Now, she works for Microsoft. She also created and promoted 
own printshop with Go-related merch with help of official Go community 
channels: conferences, social networks, slack, etc. So, the interesting 
thing is that in the post in Go blog it was claimed that 100% of money from 
new "official" store will go to so-called non-profit org "GoBridge": 
https://github.com/gobridge/about-us
which is also seems to be founded or co-founded by her, along with other 
existing Google and (perhaps some of the) ex-Google employees: 
https://github.com/gobridge/about-us#leadership-team
Ashley McNamara name there on the first place.

You can Google a lot with her name and "GoBridge", "Woman Who Go" and other 
keywords. For example here is her Patreon where she collects donations for 
Go-related artworks, and also mentions that "Woman Who Go" and "GoBridge" 
are being merged: https://www.patreon.com/posts/women-who-go-24864094

So all money will still go to that same project but now with promotion made 
on very top level, in official Go Programming Language blog. Even if that 
org is true and registered "non-profit" org, I suspect it still pays 
salaries and give contracts to sub-contractors. I tried to find any 
financial reports and proofs or evidence of real actions taken, but all I 
found is some very general stuff. At least it very suspicious. I don't 
believe that Google can't fund such a non-profit initiative without 
affecting true artists.

And apparently, very unlikely, that you paid a cent to any independent 
artist over that years.



On Friday, July 19, 2019 at 6:13:26 AM UTC+3, andrey mirtchovski wrote:

> really? throughout the years (and I've been here since the beginning) 
> i have spent infinitely more on non-google "go" merch than on google 
> go merch: stickers, t-shirts, campaigns supporting women who code, 
> etc, etc. 
>
> come on. get off your high horse. 
>

-- 
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/39fb6e76-6acb-4470-b249-bcb202580d45%40googlegroups.com.

Re: [go-nuts] Re: About the Google logo on the new Go website

[Space A.]

Funny thing that today Google has announced "official" store for Go-related
merch, which in it's essence is a try to take away even an even tiny
business opportunities for artists who were creating some goods and had a
very very little outcome on this. Now they will have ZERO.

Well done Google.


> Open source programmers have families that need food and housing, they
need companies that are willing to compensate them for their work. We need
to give thanks for those who support the language, not just Google, but
everyone.

-- 
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/CADKwOTebUiRHxz3vc-Z%2BPfiv1AGUi28E2nmTe1iM4F784_QVWw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: About the Google logo on the new Go website

[Space A.]

Others already replied about Oracle, and I don't want to go OT here, just a
small remark: you a wrong saying that VS Code is free. You are not paying
bills directly, that's correct. But it is not quite true that you are not
paying at all. It's just a different business model, first of all letting
Microsoft have close connection to wide dev audience and push and advertise
for own technologies, such as azure.
And if next time you start imagine that something made by corp is free,
just think for a while who at the end of the day pays for the party. And
where these money taken from.


ср, 17 июл. 2019 г. в 09:07, Michael Jones :

> I'm a reader here, so @all includes me. In regards to Oracle, I was
> delighted when they released VirtualBox under GPL and remain delighted that
> they pay Oracle employees to enhance it and share their work. When they
> write (https://www.virtualbox.org)...
>
> *"VirtualBox is being actively developed with frequent releases and has an
> ever growing list of features, supported guest operating systems and
> platforms it runs on. VirtualBox is a community effort backed by a
> dedicated company: everyone is encouraged to contribute while Oracle
> ensures the product always meets professional quality criteria."*
>
>
> ...I find that a logical explanation and a mutually beneficial outcome.
> The name 'Oracle' on that page does not discomfort me, nor does it upset me
> that the remarkable and free VS-Code admits to Microsoft's parentage--I
> thank them for that. I feel the same way about Google staffing Go with my
> computer science heroes (Ken Thompson et al!), building a wonderful
> language, application-level operating system, rigorous spec, two compilers,
> and open sourcing every bit of it. I am grateful, respectful, and
> absolutely stunned at your vitriol in response to gifts that none of us
> earned. It feels base and unseemly to me. Maybe you could reconsider your
> posture.
>
> Michael Jones
> Ever grateful for manna from heaven
>
> On Tue, Jul 16, 2019 at 9:05 PM Anca Emanuel 
> wrote:
>
>> @all, what do you think of Oracle ?
>> That is not an company, that is an monster.
>>
>> On Monday, July 15, 2019 at 6:40:19 PM UTC+3, Michal Strba wrote:
>>>
>>> As you all know, the new, redesigned Go website has a Google logo in the
>>> bottom right corner.
>>> Someone opened an issue about this, worrying that with the logo, nobody
>>> will see Go as a community project:
>>> https://github.com/golang/go/issues/33021
>>>
>>> The issue was promptly closed and locked by a Go team member, which I
>>> must admit, is kind of an unfair move.
>>> If you read this thread on r/programming, it seems like the worries are
>>> quite justified:
>>> https://www.reddit.com/r/programming/comments/ccidly/golang_issue_ticket_remove_the_google_logo/
>>>
>>> I personally am fine with the logo.
>>>
>>> What do you think? For example, Rust has no Mozilla logo on its page
>>> despite being largely funded by it.
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/708a60a4-0ad2-41f6-a997-8fa6c5f83e53%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
>
> *Michael T. jonesmichael.jo...@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/9gKxXmDT34k/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CALoEmQxy2aSEQGQuUyQNUwDfc4rNYR1_YYYmw7tP2Mih8EuAzA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CADKwOTcjW_0nJFr1svitpb1%3DiAYwD%2B8oDZ7fXO-H%2B%3DQ0MKN-tw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: About the Google logo on the new Go website

[Space A.]

Yep, and if you spend hours or weeks or months on contribution to this
"free" tool which they claimed is owned to community, it's your problem.
You just worked fo free for a great company. Be proud. Say hi to those guys
who got paid and live in California.
And, btw, they not just put logo, recently they also put a trademark on
language name.

вт, 16 июл. 2019 г. в 23:30, JuciÊ Andrade :

> So a company spend millions on a tool that everybody may use freely and
> when they put a simple logo in the project page the sky falls down.
>
> Are you serious, people? I find hard to believe we are discussing that.
>
>
> --
> 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/9gKxXmDT34k/unsubscribe.
> To unsubscribe from this group and all its topics, 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/add3a1b5-fb89-42ea-bad5-d99c02a3c5ed%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CADKwOTcRjEGdgV7_-E0r3FBQ%3DQPNo-WF1BJqr71EbC5eQAyr6A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] About the Google logo on the new Go website

[Space A.]

Lol. You ARE paying Google, every time you buy almost anything in this
world. It's like invisible tax. Learn how modern advertisement models
works, where the main channels are and think who, at the end, pays for
marketing budgets. Think about it when you'll be at the store next time.


It is a delusion that a bunch of **non paying** users of free goods of any
> corporation can "push back against" or "demand" something from said
> corporation. It was a delusion from the start that Go is not tightly
> coupled
> with the corporation that poured $200M in Go then made it open-sourced
> for all reasons some people raise as "evil" (while those are just
> profitable).
>
>

-- 
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/CADKwOTdxu36X982M3xezisDU4DsevT735OwvpWXV3r8_LycFuQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: About the Google logo on the new Go website

[Space A.]

Of course Google is not making money of Go directly, it would be a
non-sense. As I said, it's one of the tools they invested in, which helped
them in making zillions including building and maintaining infrastructure,
cutting the the costs, etc. That's why it is what it is. Even if they just
play a little and trough it away because it didn't work, it's pure business
investment, good or bad decision of particular manager, not because they
wanted to make a "gift" to society or a human kind as some trying to say in
this thread.

вт, 16 июл. 2019 г. в 06:55, Marcin Romaszewicz :

> I used to work at Google at the time that Go was created, and these are my
> own observations. Google isn't making zillions off Go. Google makes
> zillions off advertising and is trying to make money other ways, but not
> always very successfully. Go really was designed as a nice to use systems
> language and released to the community with good intentions. I've been gone
> from Google for a long time, but as an external observer now, I don't see
> them trying to subvert it in some self serving way. Look at how Oracle went
> after Java users for an example of what companies can do. Do you see any
> evidence of Google trying to position Go to make them zillions of bucks?
>
>
>
> On Mon, Jul 15, 2019 at 8:08 PM Space A.  wrote:
>
>> Google invested in a tool for themselves, which helped a lot in getting
>> some zillions of bucks as return. Corps open smth to communities not
>> because they a "good", but because at some point they smart enough to make
>> others work for free. There is no reason to keep implementation of
>> programming language closed. Mean time there is no cross-platform library
>> for GUI (in spite that it's called "general purpose language", not
>> "language for servers and cli" as it looks like), and door to Android is
>> closed. But you can say thank you for DART language and Flutter.
>>
>>
>> On Monday, July 15, 2019 at 8:49:10 PM UTC+3, B Carr wrote:
>>>
>>> Google has spent and is spending 10s of millions of $$$ on the
>>> development of Go and all while continuously giving it away without strings
>>> attached.
>>>
>>> And people have so much free time they complain about a tiny symbol in
>>> the upper left corner of the golang.org website?
>>>
>>> Thank you to the Go Developers, Go Contributors and Google!
>>>
>>> --
>> 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/4e4c0718-8673-420e-8826-398383300f4d%40googlegroups.com
>> <https://groups.google.com/d/msgid/golang-nuts/4e4c0718-8673-420e-8826-398383300f4d%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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/CADKwOTe4UPbwyoi%2BvQfSGro%3DN_hj54O0vHSC853dDPV4%3Dm%2Bwtg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: About the Google logo on the new Go website

[Space A.]

Google invested in a tool for themselves, which helped a lot in getting 
some zillions of bucks as return. Corps open smth to communities not 
because they a "good", but because at some point they smart enough to make 
others work for free. There is no reason to keep implementation of 
programming language closed. Mean time there is no cross-platform library 
for GUI (in spite that it's called "general purpose language", not 
"language for servers and cli" as it looks like), and door to Android is 
closed. But you can say thank you for DART language and Flutter. 


On Monday, July 15, 2019 at 8:49:10 PM UTC+3, B Carr wrote:
>
> Google has spent and is spending 10s of millions of $$$ on the development 
> of Go and all while continuously giving it away without strings attached.
>
> And people have so much free time they complain about a tiny symbol in the 
> upper left corner of the golang.org website?
>
> Thank you to the Go Developers, Go Contributors and Google!
>
>

-- 
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/4e4c0718-8673-420e-8826-398383300f4d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: General thoughts about new proposals

[Space A.]

Well said! +1

On Thursday, July 4, 2019 at 1:02:45 PM UTC+3, Slawomir Pryczek wrote:
>
> Following this group for couple years and I think that from some time the 
> community is in some kind of crisis, because it seems that go1 is so good 
> that there's a lack of some feature which will distinct go1 from go2, so 
> everyone's trying to invent some code breaking change which will "distinct" 
> 1 from 2 just for the sake of breaking backward-compatibility. There are no 
> real issues with language design, so people seems to be "inventing" 
> problems ;)
>
> So we're having a flood of different specs, which are trying to "fix" 
> something that's not broken by adding needless complexity or adding a 
> "feature" from C or Java which is more complicated than the whole go1 when 
> we look at it for more than 2 minutes. And go1 is so good it seems so easy 
> to introduce couple of very bad ideas into the language because in the end 
> it'll still looks nice.
>
> Generics, operator overloading, memory ownership, try-catch, precalculated 
> functions, and the list could go on-and-on. There's C++, everyone's 
> favourite "missing feature" is already there ... probably that's why it's 
> such a delight to write anything in it with >1 person in team ;) And if you 
> "just" miss try/catch and generics it's called java. So much effor went 
> into making go simple to read and develop, and to remove all "dust" which 
> C++ gathered over the years, now I think so much thinking goes into 
> bringing it all back. I think when creating specs people are totally 
> missing the point... we thankfully don't have to deal with overloading or 3 
> different kind of for-loops so we can focus on algorithms because code is 
> easy to read. Since when replacing 3 different loop keywords for 3 
> different conditional keywords plus adding code fragmentation sounds like a 
> good idea? So when reading single line, we'll have to check specs and maybe 
> 4 other places in the file to be kind-of-sure what it does, like it happens 
> in C++, just to save a newline...
>
> It's really not about the specs, but the amount of support every change 
> usually gets, seems just for the sake of changing something. I'm afraid 
> some of these could be introduced, and the language will be going towards 
> becoming some kind of bad c++ clone. And we could end up with something 
> even as bad and unstable as node-js very quickly, because it seems that 
> currently google is the only force which keeps potential feature creep in 
> check. Really surprising how fast people forgot how horrible try/catch or 
> generics are. And (especially for generics and overloading) - how 
> unreadable and unmaintainable code using it really is. For sure there's 
> room for improvement by inventing some new ways of doing things... not 
> forcefully porting bad, decades old, error prone "ways of thinking" from 
> C'ish languages, so we can spare a newline here and there or avoid typing 3 
> chars...
>
> So just my 2c for keeping simplicity. And if go2 can compile go1 code 
> without changes, that's actually a feature not a "problem" and anyone can 
> create overly complicated system, so yes simplicity isn't a "problem" as 
> well ;)
>

-- 
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/5a9898a7-d662-4e17-ba2d-047322071636%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Not receiving email digests

[Space A.]

Same.

On Thursday, July 11, 2019 at 2:33:46 AM UTC+3, amr wrote:
>
> I appear to be no longer receiving the email digests daily. I last 
> received a daily on 26th June, and then a single daily on 2nd July. I tried 
> leaving the group and rejoining yesterday, to no avail!
> Any ideas, please, moderator?
>

-- 
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/e643f2a0-17c7-4519-a4e6-30ff64b701db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Space A.]

Did you ever read below the title, or just seen the heading and immediately
start this teachings of emotional posts in your emotional write-up? Some
ppl see more, e.g. they can see what is the destination after first step
made. It's not the fist time ever, when someone trying to "improve" the
language by better error handling or bloody generics.


 > But instead of bringing constructive arguments to improve the proposal,
many comments are about killing the proposal, "leave if != err alone", and
change nothing. These comments summon the "community", but I'm afraid it's
not the kind of community I want to be in.

-- 
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/CADKwOTegwxFtk1stvsDouCKuYjAnHUxHx1vNX6BmQr9Agvyv3g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Space A.]

It's so nice when someone is facing audience of thousands of users by 
"where were you"? Maybe it's because they have not too much time to read 
all these forum threads, they just use the tool instead of talking, and 
also want to leave some time for a personal life?

May I ask, where were those surveys and how this could happen that so many 
ppl opinions left with no attention? 



On Saturday, June 29, 2019 at 11:15:12 PM UTC+3, andrey mirtchovski wrote:
>
> > This issue seems to have resonated with a lot of people, which may be an 
> important data point when considering the try proposal 
>
> Where were all those people when the Go Surveys were being taken the 
> last few years?
>

-- 
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/7dda93cc-2d5e-4636-b96d-8aca26b0ebb3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Interesting public commentary on Go...

[Space A.]

Debian users vote for someone to become Debian Developer and give him right
to vote? If no, how can it be "representative"?


пн, 27 мая 2019 г. в 08:35, 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com>:

> This is a bit of an aside, I agree with everything Ian said, but:
>
> On Thu, May 23, 2019 at 7:59 PM Ian Lance Taylor  wrote:
>
>> If a language is to change over time, this specification or
>> implementation must change.  Somebody has to decide how changes will
>> be made.  All successful languages have a small set of people who make
>> the final decisions.
>>
>> *Many people will provide input to this decision, but no successful
>> language--indeed, no successful free software project of any sort--is a
>> democracy. * Successful languages pay
>> attention to what people want, but to change the language according to
>> what most people want is, I believe, a recipe for chaos and
>> incoherence.  I believe that every successful language must have a
>> coherent vision that is shared by a relatively small group of people.
>>
>> As I said, that is my opinion, but I think it's true.  I would be
>> interested to hear of a counter-example.
>>
>
> I also believe that every successful free software project has a small set
> of final deciders, but I don't think it's correct to say that thus, no
> successful free software project is a democracy. Representative democracy
> is still democracy - and indeed, any modern democracy I'm aware of, is a
> representative one. And Debian is undeniably successful and very easily
> defended to be a representative democracy. There is a limitation on voting
> rights (only Debian Developers can vote), but it's akin to the limitation
> of passports and the set of Debian Developers is hardly "small".
>
> This just as a specific counter because you asked for counter examples :)
> Personally (opinion!), I tend to think that it rather supports your larger
> point of democratic software development being a recipe for chaos and
> incoherence - but YMMV of course.
>
>
>>
>> Since Go is a successful language, and hopes to remain successful, it
>> too must be open to community input but must have a small number of
>> people who make final decisions about how the language will change
>> over time.
>>
>> So, I think that when the blog post says that Go is Google's language,
>> what they mean is that Google makes those final decisions.
>>
>> Now a bit of personal history.  The Go project was started, by Rob,
>> Robert, and Ken, as a bottom-up project.  I joined the project some 9
>> months later, on my own initiative, against my manager's preference.
>> There was no mandate or suggestion from Google management or
>> executives that Google should develop a programming language.  For
>> many years, including well after the open source release, I doubt any
>> Google executives had more than a vague awareness of the existence of
>> Go (I recall a time when Google's SVP of Engineering saw some of us in
>> the cafeteria and congratulated us on a release; this was surprising
>> since we hadn't released anything recently, and it soon came up that
>> he thought we were working on the Dart language, not the Go language.)
>>
>> Since Go was developed by people who worked at Google, it is
>> inevitable that the people who initially developed Go, who became the
>> core Go team, were Google employees.  And it happens that of that core
>> Go team, while not all are actively working on Go, none have left
>> Google for another company in the years since.
>>
>> I do think that due to Go's success there are now Google executives
>> who know about Go.  Google as a company is doing more work with Go at
>> a higher level, supporting efforts like the Go Cloud Development Kit
>> (https://github.com/google/go-cloud).  And, of course, Go is a
>> significant supporting element for major Google Cloud projects like
>> Kubernetes.
>>
>> But (and here you'll just have to trust me) those executives, and
>> upper management in general, have never made any attempt to affect how
>> the Go language and tools and standard library are developed.  Of
>> course, there's no reason for them to.  Go is doing fine, so why
>> should they interfere?  And what could they gain if they did
>> interfere?  So they leave us alone.
>>
>> In effect, then, the current state is what the blog post suggests at
>> the very end: final decisions about the Go language are made by the
>> core Go team, and the core Go team all work at Google, but there is no
>> meaningful sense in which Google, apart from the core Go team, makes
>> decisions about the language.
>>
>> I do think that it will be interesting to see what happens if someone
>> on the core Go team decides to leave Google and but wants to continue
>> working on Go.  And it will be interesting to see what the core Go
>> team, including me, decides to do about succession planning as time
>> goes on.  Being a core Go team member is a full time job, and many
>> people who want to work 

Re: [go-nuts] distribution of go executables

[Space A.]

I could, of course, however I never did. And I'd like to keep myself out of
the scope of discussion. If you re-read my messages, you'll find they were
focused on topic, not shifting to persons. Thank you for your
participation, it's always good to hear different opinions, even if they
are not correct.

ср, 27 февр. 2019 г. в 23:35, Dan Kortschak :

> You're claiming expertise in copyright law in at least two
> jurisdictions, and claiming greater understanding of Australian
> copyright legislation than a person who has had training in Australian
> copyright legislation as part of their employment.
>
> I'm done here.
>
> On Wed, 2019-02-27 at 23:19 +0300, Space A. wrote:
> > Sorry? You have poor understanding and mess things, so what's wrong?
> > Being
> > dilatant is not crime, it's okay unless you start convincing yourself
> > that
> > false is true.
> >
> > ср, 27 февр. 2019 г. в 22:41, Dan Kortschak :
> >
> > >
> > > Pull your head in and stop being rude to people here.
> > >
> > > On Wed, 2019-02-27 at 17:19 +0300, Space A. wrote:
> > > >
> > > > You have very poor understanding of the subject, messing
> > > > everything
> > > > up.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

[Space A.]

Sorry? You have poor understanding and mess things, so what's wrong? Being
dilatant is not crime, it's okay unless you start convincing yourself that
false is true.

ср, 27 февр. 2019 г. в 22:41, Dan Kortschak :

> Pull your head in and stop being rude to people here.
>
> On Wed, 2019-02-27 at 17:19 +0300, Space A. wrote:
> > You have very poor understanding of the subject, messing everything
> > up.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

[Space A.]

GPL is another license with different terms, I would say offtopic.

ср, 27 февр. 2019 г. в 21:55, Robert Engels :

> You are not correct. You might wish to read this
> https://en.m.wikipedia.org/wiki/GPL_linking_exception which covers many
> of the same issues, and how they think they resolved it.
>
> On Feb 27, 2019, at 12:45 PM, Space A.  wrote:
>
> It's very clear case. It will never become a case in a court. Otherwise,
> if it ever will, I mean, compiling own program and distributing a binary
> which used stdlib e.g. without kissing someone's ass - language is dead.
>
>
>
> ср, 27 февр. 2019 г. в 21:39, Robert Engels :
>
>> That is incorrect thinking. And again, it is all subject to litigation.
>> Whether you are right or wrong is up to the courts to decide.
>>
>> On Feb 27, 2019, at 8:55 AM, Space A.  wrote:
>>
>> Regarding runtime - it's interesting (and separate question maybe), and I
>> would argue that runtime IS part of language itself because language is not
>> only a syntax. It also a garbage collector, a goroutines, etc, as you
>> mentioned. You just can't write Go program without having runtime. It's not
>> possible. So, that means that being part of the language, according to
>> copyright laws, runtime can't be covered by copyright and restricted by a
>> license.
>>
>> ср, 27 февр. 2019 г. в 17:36, 'David Golden' via golang-nuts <
>> golang-nuts@googlegroups.com>:
>>
>>> On Wed, Feb 27, 2019 at 9:20 AM Space A.  wrote:
>>>
>>>> There is no "derivatives" in Go's license terms *at all*. There is
>>>> only redistribution in binary and source form and it covers only what's in
>>>> the repo (https://github.com/golang/go/blob/master/LICENSE).
>>>>
>>>> Compilation is not redistribution.
>>>>
>>>> For a C compiler that could be true.  For Go's compiler, it also
>>> compiles the source code in the repo for the runtime -- e.g. memory
>>> allocation, garbage collection, concurrency management, etc.  If a program
>>> uses any of the core Go libraries, the same applies.  That source code is
>>> being "redistributed in binary form" by being statically compiled into the
>>> final executable.
>>>
>>> Thus, distribution of a Go executable requires including third party
>>> notices to cover the redistribution of the runtime and core libraries
>>> compiled into that executable.
>>>
>>> Regards,
>>> David
>>>
>>>
>>> --
>>> 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/6cNpXIE_18c/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> golang-nuts+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

[Space A.]

It's very clear case. It will never become a case in a court. Otherwise, if
it ever will, I mean, compiling own program and distributing a binary which
used stdlib e.g. without kissing someone's ass - language is dead.



ср, 27 февр. 2019 г. в 21:39, Robert Engels :

> That is incorrect thinking. And again, it is all subject to litigation.
> Whether you are right or wrong is up to the courts to decide.
>
> On Feb 27, 2019, at 8:55 AM, Space A.  wrote:
>
> Regarding runtime - it's interesting (and separate question maybe), and I
> would argue that runtime IS part of language itself because language is not
> only a syntax. It also a garbage collector, a goroutines, etc, as you
> mentioned. You just can't write Go program without having runtime. It's not
> possible. So, that means that being part of the language, according to
> copyright laws, runtime can't be covered by copyright and restricted by a
> license.
>
> ср, 27 февр. 2019 г. в 17:36, 'David Golden' via golang-nuts <
> golang-nuts@googlegroups.com>:
>
>> On Wed, Feb 27, 2019 at 9:20 AM Space A.  wrote:
>>
>>> There is no "derivatives" in Go's license terms *at all*. There is only
>>> redistribution in binary and source form and it covers only what's in the
>>> repo (https://github.com/golang/go/blob/master/LICENSE).
>>>
>>> Compilation is not redistribution.
>>>
>>> For a C compiler that could be true.  For Go's compiler, it also
>> compiles the source code in the repo for the runtime -- e.g. memory
>> allocation, garbage collection, concurrency management, etc.  If a program
>> uses any of the core Go libraries, the same applies.  That source code is
>> being "redistributed in binary form" by being statically compiled into the
>> final executable.
>>
>> Thus, distribution of a Go executable requires including third party
>> notices to cover the redistribution of the runtime and core libraries
>> compiled into that executable.
>>
>> Regards,
>> David
>>
>>
>> --
>> 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/6cNpXIE_18c/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

[Space A.]

Same again, messing everything. It's not API, we are talking about
distributing compiled executables.


ср, 27 февр. 2019 г. в 21:36, Robert Engels :

> You are not correct. There are current cases where apis are being claimed
> to be copyrighted. It is under active litigation.
>
> On Feb 27, 2019, at 8:19 AM, Space A.  wrote:
>
> You have very poor understanding of the subject, messing everything up.
> There is no "derivatives" in Go's license terms *at all*. There is only
> redistribution in binary and source form and it covers only what's in the
> repo (https://github.com/golang/go/blob/master/LICENSE).
>
> Compilation is not redistribution.
>
> PS: Don't want to spend to much time on this, but just to point out -
> derivative is NOT a kind of sophistic mess when something is just based on
> something. You can fork stdlib, add some extra changes and distribute it as
> "stdlib v.2 improved" - in this case this would become derivative. If you
> just use stdlib for your work, your work is not derivative from stdlib. And
> if you want to talk in copyright laws terms, lets start from the point that
> programming languages can't be protected by copyright at all (like "idea",
> "concept", etc - same).
>
> The short answer to this question is that a
>> lawyer should be consulted.
>>
>
> This is 100% clear case and you can distribute your compiled binaries
> free, without any additional requirements, restrictions, giving or not
> credits, or binding yourself to some specific license, what so ever.
> C'mon guys.
>
>
>
>
> ср, 27 февр. 2019 г. в 07:24, Dan Kortschak :
>
>> In-line
>>
>> On Wed, 2019-02-27 at 06:31 +0300, Space A. wrote:
>> > Executable is not derivative work to stdlib or anything.
>>
>> I think you'll find this is not the case in most jurisdictions. It is
>> certainly not true here, and probably also not in the US.
>>
>> From https://www.copyright.gov/circs/circ14.pdf
>>
>> "A derivative work is a work based on or derived from one or more
>> already existing works."
>>
>> > Go's repo license covers only repo.
>>
>> No.
>>
>> Point 2:
>>
>> "Redistributions in binary form must reproduce the above
>> copyright notice, this list of conditions and the following disclaimer
>> in the documentation and/or other materials provided with the
>> distribution."
>>
>> Note that redistribution is based on the notion of derivative works
>> above. The binary is a derivative of the source code, which is, in this
>> case the standard library.
>>
>> > Stdlib is not redistributed when you compile binary.
>>
>> Yes it is, in a derivative form.
>>
>> > It has nothing to do with GPL.
>>
>> The licenses are different. In this sense you are absolutely correct,
>> this has nothing to do with the GPL. However, in another, far more
>> correct sense, it is indeed related. Both the GPL and the BSD3 are
>> based on the notions that make copyright work. The licensing of the
>> work is based on that fact that the copyright owner has a sole right to
>> distribute the work. This is licensed to the recipient under a set of
>> conditions based on well established definitions of "derivative" and
>> "redistribute". Those two terms are shared by the GPL and BSD3.
>>
>> Note that the LGPL goes to lengths to distinguish between the binary of
>> the licensed work and items that are derivative, but dynamically
>> linked, purely because of the connection between the original source
>> and the binary that is the resulting executable (i.e. not the binary
>> representation of the library).
>>
>> > Go's license is simple and clear.
>>
>> And yet, here we are. The short answer to this question is that a
>> lawyer should be consulted.
>>
>>
>> >
>> > ср, 27 февр. 2019 г., 6:00 Dan Kortschak :
>> >
>> > >
>> > > Probably not. The executable is a derivative work under most
>> > > understandings (this is the basis for the GPL to require that
>> > > source
>> > > code be provided if the executable is distributed to an end user).
>> > >
>> > > Any work writen in Go, using the stdlib (which includes runtime, so
>> > > all
>> > > Go programs) is derivative of the stdlib. This means that the Go
>> > > license pertains.
>> > >
>> > > On Tue, 2019-02-26 at 18:35 -0800, Space A. wrote:
>> > > >
>> > > > You are wrong.
>> > &

Re: [go-nuts] distribution of go executables

[Space A.]

 No that means that it will depend on what's written in this particular
license given by creator of this source codes. It's case by case. For
example they can say that compilation is not allowed at all. Go's repo
license is clear without any "derivatives" "commercial" or "personal"
complex use cases, etc.

ср, 27 февр. 2019 г. в 17:55, Jan Mercl <0xj...@gmail.com>:

> On Wed, Feb 27, 2019 at 3:47 PM Space A.  wrote:
>
> > Mentioned license doesn't cover binaries produced by compiler, "binary
> form" there means go tools themselves ...
>
> That would mean that once a copyrighted source code is compiled to binary
> form, the source code copyright holders LICENSE terms no more apply.
>
> That's not the case in most jurisdictions. Proof by contradiction is left
> as an exercise...
>
> --
>
> -j
>
> --
> 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/6cNpXIE_18c/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

[Space A.]

Regarding runtime - it's interesting (and separate question maybe), and I
would argue that runtime IS part of language itself because language is not
only a syntax. It also a garbage collector, a goroutines, etc, as you
mentioned. You just can't write Go program without having runtime. It's not
possible. So, that means that being part of the language, according to
copyright laws, runtime can't be covered by copyright and restricted by a
license.

ср, 27 февр. 2019 г. в 17:36, 'David Golden' via golang-nuts <
golang-nuts@googlegroups.com>:

> On Wed, Feb 27, 2019 at 9:20 AM Space A.  wrote:
>
>> There is no "derivatives" in Go's license terms *at all*. There is only
>> redistribution in binary and source form and it covers only what's in the
>> repo (https://github.com/golang/go/blob/master/LICENSE).
>>
>> Compilation is not redistribution.
>>
>> For a C compiler that could be true.  For Go's compiler, it also compiles
> the source code in the repo for the runtime -- e.g. memory allocation,
> garbage collection, concurrency management, etc.  If a program uses any of
> the core Go libraries, the same applies.  That source code is being
> "redistributed in binary form" by being statically compiled into the final
> executable.
>
> Thus, distribution of a Go executable requires including third party
> notices to cover the redistribution of the runtime and core libraries
> compiled into that executable.
>
> Regards,
> David
>
>
> --
> 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/6cNpXIE_18c/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

[Space A.]

 Jan, good that you read my link, however I already answered on this
(quoting myself):

Mentioned license doesn't cover binaries produced by compiler, "binary
> form" there means go tools themselves, and stdlib only when redistributed
> separately as a whole in binary form. When stdlib is used to compile
> regular binary, it's not "redistributed", and there are no restrictions or
> special requirements at all.
>

What you're saying

> By distributing a program compiled by the Go compiler, one is distributing
> the binary form of some parts of the run time library and also possibly the
> binary form of some parts of the standard library, all of which are covered
> by the said LICENSE.
>

No, No, and yet one time No. You are wrong. By distributing your compiled
binary you are not "distributing" anything from the repo and it's not the
LICENSE's covered case. You are not restricted in any way.


ср, 27 февр. 2019 г. в 17:41, Jan Mercl <0xj...@gmail.com>:

> On Wed, Feb 27, 2019 at 3:20 PM Space A.  wrote:
>
> > This is 100% clear case and you can distribute your compiled binaries
> free, without any additional requirements, restrictions, giving or not
> credits, or binding yourself to some specific license, what so ever.
>
> That's not correct. Quoting from
> https://go.googlesource.com/go/+/refs/heads/master/LICENSE
>
> =
> Redistribution and use in source and binary forms, with or without
> modification, are permitted provided that the following conditions are
> met:
>
> ...
>
> * Redistributions in binary form
>
>
> *must reproduce the above copyright notice, this list of conditions and
> the following disclaimer in the documentation and/or other materials
> provided with the distribution.*
>
> ...
> =
>
> By distributing a program compiled by the Go compiler, one is distributing
> the binary form of some parts of the run time library and also possibly the
> binary form of some parts of the standard library, all of which are covered
> by the said LICENSE.
>
> The LICENSE mandates that this can be legally done only while satisfying
> the conditions highlighted above.
>
> --
>
> -j
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

[Space A.]

 You have very poor understanding of the subject, messing everything up.
There is no "derivatives" in Go's license terms *at all*. There is only
redistribution in binary and source form and it covers only what's in the
repo (https://github.com/golang/go/blob/master/LICENSE).

Compilation is not redistribution.

PS: Don't want to spend to much time on this, but just to point out -
derivative is NOT a kind of sophistic mess when something is just based on
something. You can fork stdlib, add some extra changes and distribute it as
"stdlib v.2 improved" - in this case this would become derivative. If you
just use stdlib for your work, your work is not derivative from stdlib. And
if you want to talk in copyright laws terms, lets start from the point that
programming languages can't be protected by copyright at all (like "idea",
"concept", etc - same).

The short answer to this question is that a
> lawyer should be consulted.
>

This is 100% clear case and you can distribute your compiled binaries free,
without any additional requirements, restrictions, giving or not credits,
or binding yourself to some specific license, what so ever.
C'mon guys.




ср, 27 февр. 2019 г. в 07:24, Dan Kortschak :

> In-line
>
> On Wed, 2019-02-27 at 06:31 +0300, Space A. wrote:
> > Executable is not derivative work to stdlib or anything.
>
> I think you'll find this is not the case in most jurisdictions. It is
> certainly not true here, and probably also not in the US.
>
> From https://www.copyright.gov/circs/circ14.pdf
>
> "A derivative work is a work based on or derived from one or more
> already existing works."
>
> > Go's repo license covers only repo.
>
> No.
>
> Point 2:
>
> "Redistributions in binary form must reproduce the above
> copyright notice, this list of conditions and the following disclaimer
> in the documentation and/or other materials provided with the
> distribution."
>
> Note that redistribution is based on the notion of derivative works
> above. The binary is a derivative of the source code, which is, in this
> case the standard library.
>
> > Stdlib is not redistributed when you compile binary.
>
> Yes it is, in a derivative form.
>
> > It has nothing to do with GPL.
>
> The licenses are different. In this sense you are absolutely correct,
> this has nothing to do with the GPL. However, in another, far more
> correct sense, it is indeed related. Both the GPL and the BSD3 are
> based on the notions that make copyright work. The licensing of the
> work is based on that fact that the copyright owner has a sole right to
> distribute the work. This is licensed to the recipient under a set of
> conditions based on well established definitions of "derivative" and
> "redistribute". Those two terms are shared by the GPL and BSD3.
>
> Note that the LGPL goes to lengths to distinguish between the binary of
> the licensed work and items that are derivative, but dynamically
> linked, purely because of the connection between the original source
> and the binary that is the resulting executable (i.e. not the binary
> representation of the library).
>
> > Go's license is simple and clear.
>
> And yet, here we are. The short answer to this question is that a
> lawyer should be consulted.
>
>
> >
> > ср, 27 февр. 2019 г., 6:00 Dan Kortschak :
> >
> > >
> > > Probably not. The executable is a derivative work under most
> > > understandings (this is the basis for the GPL to require that
> > > source
> > > code be provided if the executable is distributed to an end user).
> > >
> > > Any work writen in Go, using the stdlib (which includes runtime, so
> > > all
> > > Go programs) is derivative of the stdlib. This means that the Go
> > > license pertains.
> > >
> > > On Tue, 2019-02-26 at 18:35 -0800, Space A. wrote:
> > > >
> > > > You are wrong.
> > > >
> > > >
> > > > среда, 27 февраля 2019 г., 5:22:12 UTC+3 пользователь Ian
> > > > Denhardt
> > > > написал:
> > > > >
> > > > >
> > > > >
> > > > > Quoting Space A. (2019-02-26 20:58:40)
> > > > >
> > > > > >
> > > > > >
> > > > > > and stdlib only when redistributed separately as a whole in
> > > > > > binary
> > > > > > form. When stdlib is used to compile regular binary, it's not
> > > > > > "redistributed"
> > > > > This is not my understanding; in general static linking
> > > > > constitutes
> > > > > distribution (though you are correct re: compiler output of
> > > > > your
> > > > > own
> > > > > code).
> > > > >
> > > > > >
> > > > > >
> > > > > > Correct answer
> > > > > The "correct answer," really, is to ask someone actually
> > > > > qualified
> > > > > to
> > > > > give you legal advice.
> > > > >
> > > > > -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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

[Space A.]

Executable is not derivative work to stdlib or anything. Go's repo license
covers only repo. Stdlib is not redistributed when you compile binary. It
has nothing to do with GPL. Go's license is simple and clear.


ср, 27 февр. 2019 г., 6:00 Dan Kortschak :

> Probably not. The executable is a derivative work under most
> understandings (this is the basis for the GPL to require that source
> code be provided if the executable is distributed to an end user).
>
> Any work writen in Go, using the stdlib (which includes runtime, so all
> Go programs) is derivative of the stdlib. This means that the Go
> license pertains.
>
> On Tue, 2019-02-26 at 18:35 -0800, Space A. wrote:
> > You are wrong.
> >
> >
> > среда, 27 февраля 2019 г., 5:22:12 UTC+3 пользователь Ian Denhardt
> > написал:
> > >
> > >
> > > Quoting Space A. (2019-02-26 20:58:40)
> > >
> > > >
> > > > and stdlib only when redistributed separately as a whole in
> > > > binary
> > > > form. When stdlib is used to compile regular binary, it's not
> > > > "redistributed"
> > > This is not my understanding; in general static linking
> > > constitutes
> > > distribution (though you are correct re: compiler output of your
> > > own
> > > code).
> > >
> > > >
> > > > Correct answer
> > > The "correct answer," really, is to ask someone actually qualified
> > > to
> > > give you legal advice.
> > >
> > > -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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

[Space A.]

You are wrong. 


среда, 27 февраля 2019 г., 5:22:12 UTC+3 пользователь Ian Denhardt написал:
>
> Quoting Space A. (2019-02-26 20:58:40) 
>
> > and stdlib only when redistributed separately as a whole in binary 
> > form. When stdlib is used to compile regular binary, it's not 
> > "redistributed" 
>
> This is not my understanding; in general static linking constitutes 
> distribution (though you are correct re: compiler output of your own 
> code). 
>
> > Correct answer 
>
> The "correct answer," really, is to ask someone actually qualified to 
> give you legal advice. 
>
> -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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

[Space A.]

Mentioned license doesn't cover binaries produced by compiler, "binary 
form" there means go tools themselves, and stdlib only when redistributed 
separately as a whole in binary form. When stdlib is used to compile 
regular binary, it's not "redistributed", and there are no restrictions or 
special requirements at all.

Correct answer: if you are using only stdlib and Go compiler to compile a 
binary - there are no requirements. If you are using 3rd parties libs / 
binaries / sources - read their licenses.



среда, 27 февраля 2019 г., 2:18:45 UTC+3 пользователь Ian Lance Taylor 
написал:
>
> On Tue, Feb 26, 2019 at 10:59 AM R Srinivasan > 
> wrote: 
> > 
> > what if any are the licensing requirements to distribute a "go" produced 
> executable? 
>
> See https://go.googlesource.com/go/+/refs/heads/master/LICENSE .  The 
> requirements are minimal. 
>
> > are there any "commercial" products built with go? 
>
> Yes, quite a few.  You may want to look at https://golang.org/wiki/GoUsers. 
>
>
> 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.