Re: [go-nuts] how to pass the following compiler/linker flags using -gccgoflags build flag

[Yonatan Gizachew]

Aha, I got the problem. I should have added -fuse-ld=gold. The following 
works well. 
go build -o libgotest.so -buildmode=c-shared -compiler=gccgo 
-gccgoflags='-fuse-ld=gold -Wl,--split-stack-adjust-size=0x8000' 
test_mmap.go

Thank you!
On Wednesday, December 23, 2020 at 3:47:50 PM UTC+9 Yonatan Gizachew wrote:

> # command-line-arguments
> /usr/bin/ld: unrecognized option '--split-stack-adjust-size=0x8000'
> /usr/bin/ld: use the --help option for usage information
> collect2: error: ld returned 1 exit status
>
> On Wednesday, December 23, 2020 at 3:38:44 PM UTC+9 Ian Lance Taylor wrote:
>
>> On Tue, Dec 22, 2020 at 10:30 PM Yonatan Gizachew  
>> wrote: 
>> > 
>> > I want to pass the '-Wl,--split-stack-adjust-size=0x8000' to the gold 
>> linker as follows: 
>> > 
>> > go build -o libgotest.so -buildmode=c-shared -compiler=gccgo 
>> -gccgoflags='-Wl,--split-stack-adjust-size=0x8000' test_mmap.go 
>> > But there s "unrecognized option" error. Could you please tell me the 
>> correct way of passing these flags? 
>>
>> What you wrote looks about right to me. What is the exact and complete 
>> output? 
>>
>> 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/3f9f85fb-eb30-428c-a43a-18d3eef12155n%40googlegroups.com.

Re: [go-nuts] how to pass the following compiler/linker flags using -gccgoflags build flag

[Yonatan Gizachew]

# command-line-arguments
/usr/bin/ld: unrecognized option '--split-stack-adjust-size=0x8000'
/usr/bin/ld: use the --help option for usage information
collect2: error: ld returned 1 exit status

On Wednesday, December 23, 2020 at 3:38:44 PM UTC+9 Ian Lance Taylor wrote:

> On Tue, Dec 22, 2020 at 10:30 PM Yonatan Gizachew  
> wrote:
> >
> > I want to pass the '-Wl,--split-stack-adjust-size=0x8000' to the gold 
> linker as follows:
> >
> > go build -o libgotest.so -buildmode=c-shared -compiler=gccgo 
> -gccgoflags='-Wl,--split-stack-adjust-size=0x8000' test_mmap.go
> > But there s "unrecognized option" error. Could you please tell me the 
> correct way of passing these flags?
>
> What you wrote looks about right to me. What is the exact and complete 
> output?
>
> 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/f6b0d853-f7a5-4fd8-8c3b-75d7370bc2ean%40googlegroups.com.

Re: [go-nuts] how to pass the following compiler/linker flags using -gccgoflags build flag

[Ian Lance Taylor]

On Tue, Dec 22, 2020 at 10:30 PM Yonatan Gizachew  wrote:
>
> I want to pass the '-Wl,--split-stack-adjust-size=0x8000' to the gold linker 
> as follows:
>
> go build -o libgotest.so -buildmode=c-shared -compiler=gccgo 
> -gccgoflags='-Wl,--split-stack-adjust-size=0x8000' test_mmap.go
> But there s "unrecognized option" error. Could you please tell me the correct 
> way of passing these flags?

What you wrote looks about right to me.  What is the exact and complete output?

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/CAOyqgcXKOk%2BnkZQTB%3D7x%2BVLB7omFU6e93GnizCoDZhdGJLCpAQ%40mail.gmail.com.

[go-nuts] how to pass the following compiler/linker flags using -gccgoflags build flag

[Yonatan Gizachew]

Hello,

I want to pass the '-Wl,--split-stack-adjust-size=0x8000' to the gold 
linker as follows:

go build -o libgotest.so -buildmode=c-shared -compiler=gccgo 
-gccgoflags='-Wl,--split-stack-adjust-size=0x8000' test_mmap.go
But there s "unrecognized option" error. Could you please tell me the 
correct way of passing these flags? 

Thank you!

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8194cdf5-5239-4054-bef4-462c893965ben%40googlegroups.com.

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

[Robert Engels]

There are many shops that exclude using certain features (eg exceptions in 
C++). It makes interoperability and using 3rd party libs more difficult (plus 
other issues) but it can be done. 

> On Dec 22, 2020, at 9:41 PM, Jeremy French  wrote:
> 
> I'd like to second the notion that the argument "if you don't like them, 
> don't use them," is an invalid argument.  Anyone who's been in the game for 
> any length of time knows that more than we'd like, we're repairing someone 
> else's code, as opposed to writing our own from scratch.  If there is a bad 
> or confusing way to write Go code, then it will be written that way by some, 
> and we'll all be forced to deal with it.
> 
> It seems to me that part of the reason that Go was ever even a necessary 
> experiment was because these other languages were trying to appeal to as many 
> use cases as possible, and the complexity and awkwardness of those languages 
> - as well as their reliance on their programmers to know the "right way" to 
> write in the language - are an unavoidable consequence of succumbing to that 
> temptation. I would channel Antoine de Saint-Exupery in this: “Perfection is 
> Achieved Not When There Is Nothing More to Add, But When There Is Nothing 
> Left to Take Away” 
> 
> I also think saying "If you want a Java-like experience, use Java" is not 
> only not a personal attack, nor an exclusionary statement, it's a perfectly 
> reasonable recommendation. Programming languages are not exclusivity clubs 
> where if you use one, you're excluded from using another.  Using the right 
> tool for the job is part of our profession.  But I think some people, myself 
> included, find that easier to do when the tools don't all look and function 
> the same way.  Having a programming language that is simple, clear, fast, and 
> easy to maintain - even if it's considered not the right tool for the job in 
> every case - is something that I think holds value to us. That might not be 
> something that would be expressed very well in a survey.
> 
>> On Tuesday, December 22, 2020 at 6:57:47 PM UTC-5 ohir wrote:
>> 
>> Artur Vianna> you can keep writing your standard Go as it never existed. 
>> 
>> L Godioleskky> those of us who want to ignore them can easily do so 
>> 
>> Nope. You can neither pretend "it never existed" nor "ignore" no part of the 
>> language. 
>> You as a programmer are supposed to read and *understand* a lot of other's 
>> code 
>> before you will start to write your part. 
>> 
>> -- 
>> Wojciech S. Czarnecki 
>> << ^oo^ >> OHIR-RIPE 
> 
> -- 
> 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/7e0e0b20-9646-43fa-a5ce-331f730c202cn%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/85157174-60EC-45EF-A27C-A2CD358B1049%40ix.netcom.com.

[go-nuts] [ANN] Feature processing in Go

[Nikolay Dubina]

*What is it?*

A module with feature transformers plus go:generate script to generate 
feature processor for your data model in Go with emphasis on convenience 
and single sample latency.

github.com/nikolaydubina/go-featureprocessing

*Features*

   - feature parity to scikitlearn
   - convenient marshaling/unmarshaling
   - no 3rd party dependencies
   - benchmarks for module
   - go:generate script that *generates benchmarks and tests* for your 
   struct
   - ~100% test coverage
   
Cheers,

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8eaff3a3-431b-4b48-9918-4ebf2a18efebn%40googlegroups.com.

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

[Jeremy French]

I'd like to second the notion that the argument "if you don't like them, 
don't use them," is an invalid argument.  Anyone who's been in the game for 
any length of time knows that more than we'd like, we're repairing someone 
else's code, as opposed to writing our own from scratch.  If there is a bad 
or confusing way to write Go code, then it will be written that way by 
some, and we'll all be forced to deal with it.

It seems to me that part of the reason that Go was ever even a necessary 
experiment was because these other languages were trying to appeal to as 
many use cases as possible, and the complexity and awkwardness of those 
languages - as well as their reliance on their programmers to know the 
"right way" to write in the language - are an unavoidable consequence of 
succumbing to that temptation. I would channel Antoine de Saint-Exupery in 
this: “Perfection is Achieved Not When There Is Nothing More to Add, But 
When There Is Nothing Left to Take Away” 

I also think saying "If you want a Java-like experience, use Java" is not 
only not a personal attack, nor an exclusionary statement, it's a perfectly 
reasonable recommendation. Programming languages are not exclusivity clubs 
where if you use one, you're excluded from using another.  Using the right 
tool for the job is part of our profession.  But I think some people, 
myself included, find that easier to do when the tools don't all look and 
function the same way.  Having a programming language that is simple, 
clear, fast, and easy to maintain - even if it's considered not the right 
tool for the job in every case - is something that I think holds value to 
us. That might not be something that would be expressed very well in a 
survey.

On Tuesday, December 22, 2020 at 6:57:47 PM UTC-5 ohir wrote:

>
> Artur Vianna> you can keep writing your standard Go as it never existed.
>
> L Godioleskky> those of us who want to ignore them can easily do so 
>
> Nope. You can neither pretend "it never existed" nor "ignore" no part of 
> the language.
> You as a programmer are supposed to read and *understand* a lot of other's 
> code
> before you will start to write your part.
>
> -- 
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE
>

-- 
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/7e0e0b20-9646-43fa-a5ce-331f730c202cn%40googlegroups.com.

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

[Wojciech S. Czarnecki]

Artur Vianna> you can keep writing your standard Go as it never existed.

L Godioleskky> those of us who want to ignore them can easily do so 

Nope. You can neither pretend "it never existed" nor "ignore" no part of the 
language.
You as a programmer are supposed to read and *understand* a lot of other's code
before you will start to write your part.

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

-- 
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/20201223005655.5dfbd492%40xmint.

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

['Axel Wagner' via golang-nuts]

On Wed, Dec 23, 2020 at 12:19 AM Space A.  wrote:

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

Sure. I might be wrong, I'm very willing to accept that possibility.
But "the Go designers where against generics" is an easily provable
statement - just find a quote saying that.

And just to pre-empt the obvious retort: Yes, I absolutely would prove my
side as well, but it's impossible to prove a negative - I can't prove that
there are no statements of that nature. There is at least some evidence
documenting what the official stance on generics has been, though:

• Ian provided an authoritative statement to that effect in this thread, as
far as he, personally is concerned
• There is this FAQ entry: https://golang.org/doc/faq#generics - it was
added two weeks before the open source release of Go, by Rob Pike, and
documents the stance "generics might be added, if we can make them work"
(which is notably different from "generics should not be in Go")
https://github.com/golang/go/commit/dd64f86e08
• Russ Cox earliest documented stance I have at hand is from a couple of
weeks *after* the open source release and it also is consistent with this
position: https://research.swtch.com/generic

I can probably come up with more sources if I really want to invest the
time. But I do feel confident that it is simply a well-documented fact,
that the statement has always been "Go might get generics, if we can figure
out a way to do it well". I am not aware of a single instance of anyone I
would consider a core Go designer that would contradict it.

How that stance was contorted into "the Go designers don't want generics"
or "Go will never have generics" is beyond me, even tough both of these
have been very persistently repeated throughout the years (the latter has
subsided a bit over the last two or three years, since it became apparent
that there is a seriously hopeful design on the way).

But, again: By all means, I'm more than willing to be proven wrong. I
haven't read everything any of them has ever said and I might very well
have missed something.


> среда, 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
> 
> .
>

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

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!

[Ian Lance Taylor]

On Tue, Dec 22, 2020 at 2:09 PM Martin Hanson
 wrote:
>
> @Ian, if you're succumbing to outside pressure, please don't.
>
> If you on the other hand is pro-generics to Go, then of course that is
> your right.
>
> I for one doesn't hope that the future of Go is going to continue down
> this road, with new proposals for change popping up on GitHub every
> other day and 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.

I am in favor of adding generics to Go if it can be done while
preserving the clarity and simplicity of the language.  See
https://blog.golang.org/why-generics (which I wrote).

I've been looking for ways to add generics to Go for a long time.  For
example, here is a proposal I wrote up in 2010:
https://go.googlesource.com/proposal/+/refs/heads/master/design/15292/2010-06-type-functions.md.
And that wasn't even the first one I wrote.  I hope they are at least
getting better over time.

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/CAOyqgcXL6LwpwwQ84RYK88WotkNC57a8%3DBK32c1%3Dm-_zS_G7BA%40mail.gmail.com.

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

[Gerald Henriksen]

On Tue, 22 Dec 2020 22:56:32 +0100, you wrote:

>> He did explicitly said in the last paragraph that Go is not driven by
>> pools (aka surveys).
>
>Please re-read!
>
>The problem is that his post is quite contradictory. On the one hand he
>states that "Go is not and never has been a poll-driven language", yet
>at the same time, "I think it's reasonable to say that there is real
>support for adding generics" - because of the result of surveys!

No contradiction in the post.

He says clearly at the end that Go is not driven by polls

What he did do is show that the surverys do show support for the
inclusion of Generics, not that the surveys drove the decision to add
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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/u9u4uftbaeeg2uduhrdhuutj9orfu6esp7%404ax.com.

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

[Ian Lance Taylor]

On Tue, Dec 22, 2020 at 1:57 PM Martin Hanson
 wrote:
>
> > He did explicitly said in the last paragraph that Go is not driven by
> > pools (aka surveys).
>
> Please re-read!
>
> The problem is that his post is quite contradictory. On the one hand he
> states that "Go is not and never has been a poll-driven language", yet
> at the same time, "I think it's reasonable to say that there is real
> support for adding generics" - because of the result of surveys!

I see no contradiction there.

These two statements can both be true: 1) the future of the Go
language is not determined by surveys; 2) we use surveys to find out
what Go users think.

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

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

[Ian Lance Taylor]

On Tue, Dec 22, 2020 at 1:46 PM Martin Hanson
 wrote:
>
> > I don't know of a poll specifically about generics. But for the past
> > several years we've done a Go community survey, and every year there
> > is significant support for adding generics to the language.
>
> So Ian, what you're saying is that for the future we can expect that
> future development of Go will be driven by surveys? And each time there
> is a significant support for adding or removing something, it will be
> done?

No, that is not what I am saying.

I was replying to Markus Heukelom comments about a poll and about
whether the community was asked whether they (the community) wanted
generics.

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/CAOyqgcXB6oDjTR6g%3D0JrX0D80OmFwfDj2_0NZx4av_LWG%3DqJ6w%40mail.gmail.com.

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

['Axel Wagner' via golang-nuts]

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+unsubscr...@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/CAEkBMfETh%3DDPf%2BkGR%2BW8b-w0C_bH_kePMYZNUTsJGtSShhKZoA%40mail.gmail.com.

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

[Martin Hanson]

> Ultimately Go is a community and polls are unavoidable. And even in
> the benevolent-dictator model, the dictator is forced by the
> community if the pressure is high enough, this has happened in a lot
> of projects like Vim and Python. And in Vim some changes only
> happened after the adoption of the NeoVim fork created community
> pressure.
>
> The community will be the force driving the project whether you want
> it or not, the difference is that the Go team is actively seeking
> feedback, instead of letting the things get out of control, and only
> then patching it up.

That's fair enough, if that is how it is. Then surely forking Go is not
going to be a problem because a large enough part of the community is
very much against changing Go.

-- 
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/6428821608675154%40iva5-58d151f416d2.qloud-c.yandex.net.

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

[Martin Hanson]

@Ian, if you're succumbing to outside pressure, please don't.

If you on the other hand is pro-generics to Go, then of course that is
your right.

I for one doesn't hope that the future of Go is going to continue down
this road, with new proposals for change popping up on GitHub every
other day and 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+unsubscr...@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.

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

[Artur Vianna]

Ultimately Go is a community and polls are unavoidable. And even in the
benevolent-dictator model, the dictator is forced by the community if the
pressure is high enough, this has happened in a lot of projects like Vim
and Python. And in Vim some changes only happened after the adoption of the
NeoVim fork created community pressure.

The community will be the force driving the project whether you want it or
not, the difference is that the Go team is actively seeking feedback,
instead of letting the things get out of control, and only then patching it
up.

Em ter., 22 de dez. de 2020 às 19:57, Martin Hanson <
greencopperm...@yandex.com> escreveu:

> > He did explicitly said in the last paragraph that Go is not driven by
> > pools (aka surveys).
>
> Please re-read!
>
> The problem is that his post is quite contradictory. On the one hand he
> states that "Go is not and never has been a poll-driven language", yet
> at the same time, "I think it's reasonable to say that there is real
> support for adding generics" - because of the result of surveys!
>
> --
> 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/7296511608674192%40sas8-b090c2642e35.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/CAE%3DAWBV_cu2X2nYJ_367zSVjBQ9R7ikuuuzzVQ6%3DPUeOi%2BiEcw%40mail.gmail.com.

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

[Martin Hanson]

> He did explicitly said in the last paragraph that Go is not driven by
> pools (aka surveys).

Please re-read!

The problem is that his post is quite contradictory. On the one hand he
states that "Go is not and never has been a poll-driven language", yet
at the same time, "I think it's reasonable to say that there is real
support for adding generics" - because of the result of surveys!

-- 
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/7296511608674192%40sas8-b090c2642e35.qloud-c.yandex.net.

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

[Artur Vianna]

He did explicitly said in the last paragraph that Go is not driven by pools
(aka surveys).

On Tue, 22 Dec 2020, 18:46 Martin Hanson, 
wrote:

> > I don't know of a poll specifically about generics. But for the past
> > several years we've done a Go community survey, and every year there
> > is significant support for adding generics to the language.
>
> So Ian, what you're saying is that for the future we can expect that
> future development of Go will be driven by surveys? And each time there
> is a significant support for adding or removing something, it will be
> done?
>
> If the future of Go is going to be dictated by surveys and as such what
> the majority wants, then clearly Go needs to fork because a lot of us
> will NEVER want that to happen. We're VERY happy with Go, just 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/6385151608673540%40iva1-b50b8ed859e3.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/CAE%3DAWBUQ5Uxq4dyMYrXqL%2Bv-gBP2p23nuDydUa2Z5akeBAiNQQ%40mail.gmail.com.

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

[Martin Hanson]

> I don't know of a poll specifically about generics. But for the past
> several years we've done a Go community survey, and every year there
> is significant support for adding generics to the language.

So Ian, what you're saying is that for the future we can expect that
future development of Go will be driven by surveys? And each time there
is a significant support for adding or removing something, it will be
done?

If the future of Go is going to be dictated by surveys and as such what
the majority wants, then clearly Go needs to fork because a lot of us
will NEVER want that to happen. We're VERY happy with Go, just 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6385151608673540%40iva1-b50b8ed859e3.qloud-c.yandex.net.

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

[Ian Lance Taylor]

On Tue, Dec 22, 2020 at 1:24 AM Markus Heukelom
 wrote:
>
> Why not issue a poll on generics, was this ever done? (I could've missed it, 
> I  am only following Go ~2 years). While the community has a vote in 
> accepting/rejecting the current generics proposal, the community was never 
> (really) asked if generics is desired in the first place and especially what 
> the scope of generics should be. Is that correct?

I don't know of a poll specifically about generics.  But for the past
several years we've done a Go community survey, and every year there
is significant support for adding generics to the language.  For
example, although the results of the 2020 survey haven't been
assembled yet, you can see the results of the 2019 survey at
https://blog.golang.org/survey2019-results.  In that survey when asked
"Which critical language features do you need that are not available
in Go?", 25% of the survey takers answered the question, and of those
79% mentioned generics.  Previous years also showed support for adding
generics.  Of course this isn't definitive, since there was no clear
way for people they say that do not want generics.  But it's also not
definitive in a different direction, which is that by and large people
who don't currently use Go didn't take the survey, and probably some
of them would also want generics.

So while Go is not and never has been a poll-driven language, I think
it's reasonable to say that there is real support for adding generics.


> Another thought:  there are many popular, type-safe programming language with 
> generics already. So if you really need generics, there's plenty to pick 
> from. There's not that many  without, I can only name Go and C. So if 
> generics is added to Go there's far less choice to pick a modern type-safe 
> language that doesn't have generics. It's a feature that makes Go quite 
> special.

Actually, C does have generics, through the preprocessor macro
mechanism.  It's difficult to write, but it does provide the same kind
of functionality that would be available in Go if we added generics.
For example, here is a compile-time-type-safe vector implementation in
C:

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/vec.h;h=cb871124ce2241402af05e4697a5e28904c462fb;hb=HEAD
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/vec.c;h=85274c4e00c202e680761cef516bd17bb58b6261;hb=HEAD

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/CAOyqgcU_rVJLP%3DG%3DdzMnvoD9HrJGBQcQ_Joc6oni2ggQxfxuqw%40mail.gmail.com.

[go-nuts] Re: Interfaces holding integers and memory allocations

[ben...@gmail.com]

Wow -- yes, that's pretty significant! (Though point taken about "real 
workloads".) Thanks for sharing this.

On Tuesday, December 22, 2020 at 11:44:25 PM UTC+13 arn...@gmail.com wrote:

> Luckily, I have the "no scalar" version with a build tag.  Here is a 
> simple benchmark:
>
> func BenchmarkValue(b *testing.B) {
> for n := 0; n < b.N; n++ {
> sv := IntValue(0)
> for i := 0; i < 1000; i++ {
> iv := IntValue(int64(i))
> sv, _ = add(nil, sv, iv) // add is the "real" lua runtime 
> function that adds two numeric values.
> }
> }
> }
>
> Results with the "scalar" version
>
> $ go test -benchmem -run=^$ -bench '^(BenchmarkValue)$' ./runtime
> goos: darwin
> goarch: amd64
> pkg: github.com/arnodel/golua/runtime
> cpu: Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
> BenchmarkValue-8  122995  9494 ns/op   0 
> B/op  0 allocs/op
> PASS
> ok  github.com/arnodel/golua/runtime1.415s
>
> Results without the "scalar" version (noscalar build tag)
>
> $ go test -benchmem -run=^$ -tags noscalar  -bench '^(BenchmarkValue)$' 
> ./runtime
> goos: darwin
> goarch: amd64
> pkg: github.com/arnodel/golua/runtime
> cpu: Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
> BenchmarkValue-8   37407 32357 ns/op   13768 
> B/op   1721 allocs/op
> PASS
> ok  github.com/arnodel/golua/runtime1.629s
>
> That looks like a pretty big improvement :)
>
> The improvement is also significant in real workloads but not.so dramatic 
> (given they don't spend all their time manipulating scalar values!)
>
>

-- 
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/95987174-9372-4a02-ba5c-8148cab31810n%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!

[burak serdar]

On Tue, Dec 22, 2020 at 12:09 PM Anthony Martin  wrote:
>
> 'Axel Wagner' via golang-nuts  once said:
> > 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.
>
> Please don't minimize or silence the lived experience
> of people disproportionately affected by generics.
>
> We should protect non-generic function bodies.

I also developed some horrendous code using generics in Java. I can
relate to the resistance many are having against generics. However,
there are some differences in the Go generics implementation that
makes me hopeful, so I suggest those who are opposed to it to give it
a chance and try it. This is not Java generics that were forced into
the language without changing the underlying JVM. Nor is it C++ (yet)
that you can't really do anything useful without writing lots of
cryptic code just to keep the libraries happy. A balanced approach in
the library that doesn't impose generics on developers at every
possible opportunity may go a long way.

>
> Concrete code matters.
>
>   Anthony
>
> --
> 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/X%2BJD0mE0ZzY7AyM2%40alice.

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

[go-nuts] `go list` across multiple modules?

['Tim Hockin' via golang-nuts]

I just can't figure out how to do this.  Maybe it can't be done in `go
list` ?  Or maybe we're just missing some detail of go modules..

I have a repo (kubernetes, but minimized at
https://github.com/thockin/go-list-modules) which has a "main" go
module, and several other modules in the same repo.  It's probable not
worth explaining the history right now, but here we are.

As part of the build, I need to run some code generators.  They are
slow, so I only want to run them if their inputs have actually
changed.  To do this, I need to build a list of all the individual
files that are transitively depended on by the package in question.

First I do a `find` for any file that has a specific comment tag,
indicating that the package needs codegen.  The results span several
of the in-repo submodules.

For each target package, I want to get the list of all deps and
extract the GoFiles.  Then I can use that to determine if the codegen
needs to run.

Where it breaks down is that I can't seem to `go list` all at once:

```
# This works within the "root" module
$ go list -f '{{.GoFiles}}' ./subdir
[file.go]

# This does not work across modules
$ go list -f '{{.GoFiles}}' ./submod/used ./submod/unused
main module (example.com/m) does not contain package example.com/m/submod/used
main module (example.com/m) does not contain package example.com/m/submod/unused

# Nor does this work, even with module replacements
$ go list -f '{{.GoFiles}}' ./staging/src/example.com/other1/used
./staging/src/example.com/other1/unused
main module (example.com/m) does not contain package
example.com/m/staging/src/example.com/other1/used
main module (example.com/m) does not contain package
example.com/m/staging/src/example.com/other1/unused
```

I can run `go list` multiple times, but that's INCREDIBLY slow - most
of these submodules have common deps that are large.  This re-parses
everything over and over.  It takes almost 60 seconds just to do `cd
$dir; go list` (on the real kubernetes repo).

I wrote a program against go/packages which does SLIGHTLY better, in
that it finds packages in other modules but ONLY if they a) are a dep
of something in the root module; and b) exist in vendor/.  Note here
that ./subir DOES depend on ./submod, but that is not listed.

```
$go2make2 -p ./subdir
Package "example.com/other1/used" {
  Name: "used"
  PkgPath: "example.com/other1/used"
  GoFiles: [
"/tmp/m/go-list-modules/vendor/example.com/other1/used/file.go"
  ]
  Imports: [
  ]
}
Package "example.com/other2/used" {
  Name: "used"
  PkgPath: "example.com/other2/used"
  GoFiles: [
"/tmp/m/go-list-modules/vendor/example.com/other2/used/file.go"
  ]
  Imports: [
  ]
}
Package "example.com/m/subdir" {
  Name: "subdir"
  PkgPath: "example.com/m/subdir"
  Module: "example.com/m"
  ModuleDir: "/tmp/m/go-list-modules"
  GoFiles: [
"/tmp/m/go-list-modules/subdir/file.go"
  ]
  Imports: [
"example.com/m/submod/used"
"example.com/other1/used"
"example.com/other2/used"
  ]
}
```

Also note that `Module` info is missing for the ones it does find.

So I guess I am looking for some magical incantation that lets me
process and load all of the files across multiple modules exactly
once.  I wrote a similar program against go/build which runs in < 3
seconds, but doesn't work properly outside of a GOPATH (not sure why).

Any clues on how to approach this better would be well appreciated.

Tim

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

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

['Carla Pfaff' via golang-nuts]

On Tuesday, 22 December 2020 at 20:09:42 UTC+1 al...@pbrane.org wrote:

> Please don't minimize or silence the lived experience 
> of people disproportionately affected by generics. 
>
> We should protect non-generic function bodies. 
>
> Concrete code matters. 
>

Tasteless attempt at humour.

-- 
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/20893718-5fd6-4ab9-b2bb-5742ef042d3cn%40googlegroups.com.

Re: [go-nuts] Performance issue with os.File.Write

[komuW]

The bufio package also uses a max buffer of 
64KB: https://go.googlesource.com/go/+/go1.15.6/src/bufio/scan.go#80  
io.copybuffer on the other hand uses 
32KB; https://go.googlesource.com/go/+/go1.15.6/src/io/io.go#398

On Monday, 21 December 2020 at 14:46:21 UTC+3 arn...@gmail.com wrote:

> @Ben interesting, I did something similar and also ended up with a 64KB 
> buffer (seemed like the default of 4KB didn't work very well in my 
> context).  How did you decide of the buffer size?
>
> Also, there is something that I don't understand.  The default buffer size 
> works really well for a toy example (like the one I posted in my original 
> question), but the improvements are much less dramatic in my program, for 
> the same pattern of writing to stdout.  I can't work out a reason for this 
> yet.
>
>
> On Sunday, 20 December 2020 at 20:31:52 UTC ben...@gmail.com wrote:
>
>> And os.Stdout (and friends) are all regular *os.File objects (which as 
>> Jan said, don't buffer). It was non-intuitive to me that stdout didn't 
>> buffer by default, because it's such a bad thing for efficiently writing 
>> lots of output, but I guess it makes sense when you want terminal output to 
>> appear right away. So I realized it made sense, and gives you more control. 
>> And it's so easy to wrap it in a bufio.NewWriter() ... Flush() if you need 
>> buffering.
>>
>> I ran into this exact same issue when implementing GoAWK ... a 10-line 
>> fix gave me a 10x speedup. 
>> https://github.com/benhoyt/goawk/commit/60745c3503ba3d99297816f5c7b5364a08ec47ab
>>
>> -Ben
>>
>> On Monday, December 21, 2020 at 12:27:43 AM UTC+13 arn...@gmail.com 
>> wrote:
>>
>>> Ah, that is it, thank you!
>>>
>>> On Sunday, 20 December 2020 at 11:06:05 UTC Jan Mercl wrote:
>>>
 On Sun, Dec 20, 2020 at 11:53 AM Arnaud Delobelle  
 wrote: 

 > TLDR; a simple test program appears to show that Go's 
 (*os.File).Write is 10x slower than C's fputs (on MacOS). 

 Apples and oranges. fputs buffers, os.File does not. Rewrite the 
 benchmark using bufio. 

>>>

-- 
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/f98810f0-9227-4002-a272-d458e21dcf2bn%40googlegroups.com.

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

[Anthony Martin]

'Axel Wagner' via golang-nuts  once said:
> 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.

Please don't minimize or silence the lived experience
of people disproportionately affected by generics.

We should protect non-generic function bodies.

Concrete code matters.

  Anthony

-- 
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/X%2BJD0mE0ZzY7AyM2%40alice.

Re: [go-nuts] Java version of keydb

[flying_dutchman]

I think it'd be a good idea if you can compile your Java port using GraalVM 
and benchmark the generated executable.

On Monday, December 14, 2020 at 2:58:15 AM UTC+5:30 ren...@ix.netcom.com 
wrote:

> I did not, and honestly it is probably not a great comparison.
>
> Java requires the JVM - which is separate - so executables sizes are hard 
> to compare. The Java ‘executable code’ is tiny.
>
> As for runtime memory usage, it is fairly trivial since the data is stored 
> on disk with an in-memory ’skip index’. The skip index is nearly identical 
> between the two - Java probably having a bit more pointer overhead - but 
> the size of the in-memory index is configurable - so trading memory for 
> speed is up to the user.
>
> There is no way to cap the heap size in Go to offer an apples-2-apples 
> comparison.
>
>
>
>
> On Dec 13, 2020, at 3:08 PM, da...@suarezhouse.net  
> wrote:
>
> Super interesting.  Did you happen to catch the runtime memory avg, 
> median, max and current "executable" file size difference?
>
> On Saturday, December 12, 2020 at 1:04:42 PM UTC-6 ren...@ix.netcom.com 
> wrote:
>
>> Hi all,
>>
>> I thought this might be of interest to some. I released a Java version of 
>> keydb  at jkeydb 
>> . I primarily did the exercise to keep 
>> my Java skills fresh and do an updated performance comparison between Go 
>> and Java.
>>
>> Tests performed using OSX Big Sur.
>>
>> Using Go 1.15.5:
>>
>> insert time  1000 records =  24670 ms, usec per op  2.4670965
>> close time  16945 ms
>> scan time  10631 ms, usec per op  1.063149
>> scan time 50%  470 ms, usec per op  0.941686
>> random access time  9.658001 us per get
>> close with merge 1 time  0.681 ms
>> scan time  11253 ms, usec per op  1.1253718
>> scan time 50%  471 ms, usec per op  0.942876
>> random access time  9.702651 us per get
>>
>> Using Java 1.15:
>>
>> insert time 1000 records = 24102ms, usec per op 2.4102
>> close time 13564ms
>> scan time 10259ms, usec per op 1.0259
>> scan time 50% 474ms, usec per op 0.948
>> random access time 13.209us per get
>> close with merge 1 time 0ms
>> scan time 10142ms, usec per op 1.0142
>> scan time 50% 501ms, usec per op 1.002
>> random access time 13.28us per get
>>
>> Performance is very similar, except that Go is significantly faster in 
>> the random access tests. I attribute this to the JNI overhead in making 
>> lots of small IO requests. In a previous life I wrote some custom JNI code 
>> for ultrafast IO and I might resurrect that to see if it makes a difference.
>>
>> You can vary the ‘keyIndexInterval’ to trade memory for speed which 
>> significantly helps the Java version by reducing the IO.
>>
>> There are significantly fewer source (non test) code files in the Go 
>> version, 10 vs. 26 which highlights the simplicity of Go.
>>
>> Anyway, feel free to ask any questions if you wish.
>>
>>
>>
> -- 
> 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/9079e608-2c6c-4547-8c27-ebbb48a2fe61n%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/37374167-c575-407f-971b-78f2b1c3131bn%40googlegroups.com.

[go-nuts] Re: mic input level

[ccahoon]

Hi again! 

Is your program getting the audio from the mic already? If so, can you give 
some details about that? If not, to build the line chart, you will first 
need to have access to the audio data from the mic in some way. 

On Monday, December 21, 2020 at 9:25:05 AM UTC-5 Jeff Mangan wrote:

> I asked a similar question recently, but have decided to approach a 
> different way.
>
> I'm looking for a way to do something similar to a standard sound record 
> app that shows a graph line chart of the input from a mic.  That's it, 
> nothing fancy doesn't need to record and save or anything. 
>
> Has anyone done or know how to do this in go?
>
> 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/df7250fc-11dc-4fac-b0b2-873a4054f115n%40googlegroups.com.

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

['Axel Wagner' via golang-nuts]

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.

On Tue, Dec 22, 2020 at 1:22 PM Space A.  wrote:

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

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

[Jan Mercl]

On Tue, Dec 22, 2020 at 1:02 PM Axel Wagner
 wrote:

> I feel well justified in calling this out as destructive behavior.

You've defined the problem much better than I could ever do. But this
one is not technical and off topic in this thread. Thanks for
considering.

-- 
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/CAA40n-XJ1Tdw3%2BaEQ_H%3DFj-Rr0m2%3DUjRibc7CjHp%2Bk-wEGfnjQ%40mail.gmail.com.

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] Re: Generics, please go away!

['Axel Wagner' via golang-nuts]

On Tue, Dec 22, 2020 at 12:46 PM Jan Mercl <0xj...@gmail.com> wrote:

> On Tue, Dec 22, 2020 at 12:01 PM 'Axel Wagner' via golang-nuts
>  wrote:
>
> > 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
>
> I have never read the CoC, but I don't expect it justifies implanting
> irrelevant social issues into a technical discussion like this to be
> used as an argument against a differing opinion. Please don't, thank
> you.
>

You might want to give it a read, then. It includes "Be friendly and
welcoming" as the first Gopher value. Saying "I think people who want
generics added to Go should go and program in Java or C++" and asking "Why
are you even here!?" is clearly the opposite of welcoming.

And, FTR, saying something is "a technical discussion" doesn't make it so.
This thread is almost exclusively about *social* issues - the arguments
brought forth are mostly talking about how decisions are made, baseless
claims that generics are added solely by majority decision or polls,
fear-mongering about slippery slopes, appeals to authority and trying to
create an us-vs-them and "threatening" to split the community. There is
very little technical content here.

I feel well justified in calling this out as destructive behavior.

Back to the topic. Yes, I agree that Go is going through a serious
> case of featuritis for some time. It's sad, but knowing there's
> nothing I can do about it, I'm not really frustrated. Afterall there
> are places where generics will be just fine. I will be frustrated,
> however, when I'll have to read generic code in places where it
> shouldn't be generic. Grep would no longer point me to a particular,
> plain readable implementation, which then would have to be built
> mentally only and that will be much more complicated to do.
>
> That will happen. It happens routinely in every other programming
> language that has generics. Because for so many it's so cool to write
> write-only code.
>
> I'm sometimes a sinner too.
>

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

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

[Jan Mercl]

On Tue, Dec 22, 2020 at 12:01 PM 'Axel Wagner' via golang-nuts
 wrote:

> 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

I have never read the CoC, but I don't expect it justifies implanting
irrelevant social issues into a technical discussion like this to be
used as an argument against a differing opinion. Please don't, thank
you.

Back to the topic. Yes, I agree that Go is going through a serious
case of featuritis for some time. It's sad, but knowing there's
nothing I can do about it, I'm not really frustrated. Afterall there
are places where generics will be just fine. I will be frustrated,
however, when I'll have to read generic code in places where it
shouldn't be generic. Grep would no longer point me to a particular,
plain readable implementation, which then would have to be built
mentally only and that will be much more complicated to do.

That will happen. It happens routinely in every other programming
language that has generics. Because for so many it's so cool to write
write-only code.

I'm sometimes a sinner too.

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

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

['Axel Wagner' via golang-nuts]

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+unsubscr...@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 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/CAEkBMfE9nH1SaGUUrTUZwVR4ivYOcn3-5xGhS7WH3L1VRd7ENQ%40mail.gmail.com.

[go-nuts] Re: Interfaces holding integers and memory allocations

[Arnaud Delobelle]

Luckily, I have the "no scalar" version with a build tag.  Here is a simple 
benchmark:

func BenchmarkValue(b *testing.B) {
for n := 0; n < b.N; n++ {
sv := IntValue(0)
for i := 0; i < 1000; i++ {
iv := IntValue(int64(i))
sv, _ = add(nil, sv, iv) // add is the "real" lua runtime 
function that adds two numeric values.
}
}
}

Results with the "scalar" version

$ go test -benchmem -run=^$ -bench '^(BenchmarkValue)$' ./runtime
goos: darwin
goarch: amd64
pkg: github.com/arnodel/golua/runtime
cpu: Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
BenchmarkValue-8  122995  9494 ns/op   0 
B/op  0 allocs/op
PASS
ok  github.com/arnodel/golua/runtime1.415s

Results without the "scalar" version (noscalar build tag)

$ go test -benchmem -run=^$ -tags noscalar  -bench '^(BenchmarkValue)$' 
./runtime
goos: darwin
goarch: amd64
pkg: github.com/arnodel/golua/runtime
cpu: Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
BenchmarkValue-8   37407 32357 ns/op   13768 
B/op   1721 allocs/op
PASS
ok  github.com/arnodel/golua/runtime1.629s

That looks like a pretty big improvement :)

The improvement is also significant in real workloads but not.so dramatic 
(given they don't spend all their time manipulating scalar values!)

On Monday, 21 December 2020 at 21:02:26 UTC ben...@gmail.com wrote:

> Nice! Do you have any benchmarks on how much faster the "scalar" version 
> is than the non-scalar?
>
> On Tuesday, December 22, 2020 at 12:58:19 AM UTC+13 arn...@gmail.com 
> wrote:
>
>> Just an update (in case anyone is interested!).  I went for the approach 
>> described below of having a Value type holding a scalar for quick access to 
>> values that fit in 64 bits (ints, floats, bools) and an interface fo for 
>> the rest.
>>
>> type Value struct {
>> scalar uint64
>> iface interface{}
>> }
>>
>> That significantly decreased memory management pressure on the program 
>> for many workloads, without having to manage a pool of say integer values.  
>> It also had the consequence of speeding up many arithmetic operations.  
>> Thanks all for your explanations and suggestions!
>>
>> -- 
>> Arnaud
>>
>> On Wednesday, 16 December 2020 at 11:15:32 UTC Arnaud Delobelle wrote:
>>
>>> Ah interesting, I guess that could mean I would need to switch to using 
>>> reflect.Value as the "value" type in the Lua runtime.  I am unclear about 
>>> the performance consequences, but I guess I could try to measure that.
>>>
>>> Also, looking at the implementation of reflect, its seems like the Value 
>>> type I suggested in my reply to Ben [1] is a "special purpose" version of 
>>> reflect.Value - if you squint at it from the right angle!
>>>
>>> -- 
>>> Arnaud
>>>
>>> [1]
>>> type Value struct {
>>> scalar uint64
>>> iface interface{}
>>> }
>>> On Wednesday, 16 December 2020 at 00:56:52 UTC Keith Randall wrote:
>>>
 Unfortunately for you, interfaces are immutable. We can't provide a 
 means to create an interface from a pointer, because then the user can 
 modify the interface using the pointer they constructed it with (as you 
 were planning to do).

 You could use a modifiable reflect.Value for this.

 var i int64  = 77
 v := reflect.ValueOf().Elem()

 At this point, v now has .Type() of int64, and is settable.

 Note that to get the value you can't do v.Interface().(int64), as that 
 allocates. You need to use v.Int().
 Of course, reflection has its own performance gotchas. It will solve 
 this problem but may surface others.
 On Tuesday, December 15, 2020 at 12:04:54 PM UTC-8 ben...@gmail.com 
 wrote:

> Nice project!
>
> It's a pity Go doesn't have C-like unions for cases like this (though 
> I understand why). In my implementation of AWK in Go, I modelled the 
> value 
> type as a pseudo-union struct, passed by value:
>
> type value struct {
> typ valueType // Type of value (Null, Str, Num, NumStr)
> s   string// String value (for typeStr)
> n   float64   // Numeric value (for typeNum and typeNumStr)
> }
>
> Code here: 
> https://github.com/benhoyt/goawk/blob/22bd82c92461cedfd02aa7b8fe1fbebd697d59b5/interp/value.go#L22-L27
>
> Initially I actually used "type Value interface{}" as well, but I 
> switched to the above primarily to model the funky AWK "numeric string" 
> concept. However, I seem to recall that it had a significant performance 
> benefit too, as passing everything by value avoided a number of 
> allocations.
>
> Lua has more types to deal with, but you could try something similar. 
> Or maybe include int64 (for bool as well) and string fields, and 
> everything 
> else falls back to interface{}? It'd be a fairly large struct, so not 

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

[Martin Hanson]

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/5029411608631693%40iva7-919bb0034794.qloud-c.yandex.net.

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

[wilk]

On 21-12-2020, Martin Hanson wrote:
> I have just suggested the same thing @Space A, before I read your message and 
> I agree fully!
>
> https://github.com/golang/go/issues/15292#issuecomment-749032046
>
> I strongly believe we need to fork Go if generics gets added and then let the 
> toy people have their new shiny things in Go while we rename Go into 
> something else and stay with Go 1. Then we need to have the first and most 
> important rule, that NOTHING new gets added to Go 1.
>
> Go definitely needs a fork if generics gets added!
>

It could be easy to fork Go and just forbid generics but you'll loose
all the libs that will use generics. And it's in libs that generics is
most usefull (like interfaces) !

I'm not so afraid of generics.
When i see the last draft, we can even says that we already have a form
of generics at method level with concept of interface since beginning.
When we use io.Reader, it's generic, we don't wait for a type.
The way generic are added it's not really generics like in
other langages, it's type parameters with constraints like with
interface with method. It's not really a new concept in Go.

We already can abuse of empty interface{}. It'll be the same with type
parameters, we could abuse of type 'any' but most of the time we'll use
type parameters with constraints, like interface with method and it'll
keep strong.

Sorry for my bad english, if somebody understand and could rewrite what
i mean ?

-- 
wilk

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/rrseie%249sm%241%40ciao.gmane.io.

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

[Markus Heukelom]

Why not issue a poll on generics, was this ever done? (I could've missed 
it, I  am only following Go ~2 years). While the community has a vote in 
accepting/rejecting the current generics proposal, the community was never 
(really) asked if generics is desired in the first place and especially 
what the scope of generics should be. Is that correct? 

Another thought:  there are many popular, type-safe programming language 
with generics already. So if you really need generics, there's plenty to 
pick from. There's not that many  without, I can only name Go and C. So if 
generics is added to Go there's far less choice to pick a modern type-safe 
language that doesn't have generics. It's a feature that makes Go quite 
special.

To me, the most worrisome thing about the current generics proposal is that 
there'll be a constant choice/preference fight between writing

func MyFunc(r io.Reader) error {}

- or - 

func MyFunc[T io.Reader](r T) error {}

I hope I am wrong, but I have the feeling the latter looks cooler to a lot 
of programmers out there. 


On Sunday, December 20, 2020 at 8:38:54 PM UTC+1 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1fe5535e-9c1e-4fba-97da-1f840a284c82n%40googlegroups.com.

Re: [go-nuts] how to get unsigned url (not signed url)

[Uli Kunitz]

This assumes that you have made site publicly available as described in the 
document I have linked.

On Tuesday, December 22, 2020 at 12:59:31 AM UTC+1 Alexander Mills wrote:

> that is not a google url:
>
>  https://example.com/
>
> ?
>
> On Monday, December 21, 2020 at 3:53:37 PM UTC-8 Uli Kunitz wrote:
>
>> It is the Google Cloud Storage package. Documentation is here: 
>> https://pkg.go.dev/cloud.google.com/go/storage
>>
>> Signed URLs are URLs that allow access to an object in the cloud storage 
>> without any other authentication mechanism: 
>> https://cloud.google.com/storage/docs/access-control/signed-urls
>>
>> Google cloud storage organizes data into buckets and objects. A single 
>> site should be represented by one bucket and the files as the objects in 
>> the site. The explanation how to setup a static website with Google Cloud 
>> Storage can be found here: 
>> https://cloud.google.com/storage/docs/hosting-static-website
>>
>> The URL for an object is then https://example.com/
>>
>> On Monday, December 21, 2020 at 11:59:20 PM UTC+1 Kurtis Rader wrote:
>>
>>> On Mon, Dec 21, 2020 at 2:55 PM Alexander Mills  
>>> wrote:
>>>
 this is a little irritating lol, i can get a signed url via:

 bucket := "bnk-photos"
 filename := "mypic3.json"
 method := "PUT"
 expires := time.Now().Add(time.Minute * 10)

 url, err := storage.SignedURL(bucket, filename, 
 {
 GoogleAccessID: cfg.Email,
 PrivateKey: cfg.PrivateKey,
 Method: method,
 Expires: expires,
 ContentType: "binary/octet-stream",
 })


 but I just want an *unsigned* url?
 how?

>>>
>>> What is the "storage" package? It's not part of the Go stdlib. Also, 
>>> what is a "signed" URL. I've never heard that phrase before your email.
>>>  
>>> -- 
>>> Kurtis Rader
>>> Caretaker of the exceptional canines Junior and Hank
>>>
>>

-- 
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/79914436-dbca-4e0d-9ee1-f8ee55cf0ea4n%40googlegroups.com.