Re: [go-nuts] Proposal to add Index operator methods

[Randall O'Reilly]

I think we all agree that Python has some major issues..  :)

But the point of Jon's argument which struck me as very compelling is that Go 
would really need full operator overloading to serve as a serious competitor 
given the standards to which people have become accustomed.  I didn't see in 
your replies a clear response to that, but maybe I missed it?

The really tricky issue is that everyone wants something like Python *as a 
starting point* when just messing around, because it is so easy and flexible to 
just write simple expressions etc.  But then once things start to scale up, all 
the "issues" start to outweigh those initial advantages.  And for a huge number 
of Python users, they never scale up and don't care about anything more than 
getting their immediate needs solved, mostly by copy / paste / modify 
programming..

That's why I think the Python / Go hybrid approach could be good -- end-user 
type people can mess around in Python, but the same functionality is available 
in Go, and as stuff starts to get scaled up to the point of requiring more 
libraries, those can hopefully be done in Go, so that Python always remains on 
the "messing around" scale of things, while the deeper infrastructure gets 
built out in Go..  This probably requires a fair bit of extra work and 
motivation on the part of the Go-side developers to keep up with things and 
support the developing needs of their users, so it may not be plausible for a 
larger-scale community, but it is working pretty well for my small-scale 
biological neural network modeling community..

Functionally, it is sort of similar to having a transpiler, in that Python is 
just providing a simple front-end syntax for accessing the deeper Go 
functionality.

Anyway, wasn't Julia supposed to solve all these issues? I don't know much 
about it in detail, but I googled just to see what the latest discussion there 
is relative to Python -- this thread is informative and current:

https://discourse.julialang.org/t/why-is-python-not-julia-still-used-for-most-state-of-the-art-ai-research/45896/17

The basic thrust is that people don't care and just go with what everyone else 
is doing.  This was the best quote IMO:

> There are countries that still do not use the metric system, you figure it 
> out.

Also this is informative:

> For my subjective idea I would also say Python, as someone mentioned here, is 
> much easier language than Julia. Coming from MATLAB looking at packages of 
> Julia seems to me as an act of wizard.

Python hits a sweet spot of simplicity and power.. Julia apparently does not.  
Go hits a different such sweet spot, but not with the same kind of transparent 
syntactic expressions needed for data science / ML etc.

- Randy

> On Oct 7, 2020, at 5:49 PM, Raanan Hadar  wrote:
> 
> So we respectfully disagree here, so the best thing I can do is add some 
> quality arguments. I think this is an important discussion that might cement 
> Go as a broad DSL in the sense that it does a lot of things exceptionally 
> well, but this issue will remain a blind spot.
> 
> I fully understand the need to keep Go "pure and simple". Its the key to its 
> success. But this is an important area where Go does not have enough features 
> to be effective. Secondly, I think that solving this issue can be achieved 
> while maintaining orthogonality and not hurting experience of the majority. 
> Third, as I answered Jon, I think that looking at this proposal, or more 
> generally, this problem, from the Go programmer's perspective, is like trying 
> to optimize a local optima. Go programmers don't have much to gain from this. 
> But from a global perspective that seeks to optimize software development as 
> a whole, there's a huge benefit that is overlooked here. Go was not designed 
> to cater the needs of the programmer but software engineering as an end to 
> end process (https://talks.golang.org/2012/splash.article).
> 
> With regards to Python, I've detailed common examples in my proposal, where 
> Python for numerical computing leaves a lot to be desired. Fundamental issues 
> which Go solves by design and are not addressed effectively by putting the 
> two together as you suggested. Secondly, I am not the only one saying that 
> there is a real need for a better language than Python. To name two good 
> examples: Yann LeCun said this last year: 
> https://venturebeat.com/2019/02/18/facebooks-chief-ai-scientist-deep-learning-may-need-a-new-programming-language/
>  and Jeremy Howard, former president and chief scientist of Kaggle and the 
> author of the fast.ai, strongly advocates that Python is not the way to go in 
> long run: https://www.youtube.com/watch?v=c-KAf2g6YN4  
> 
> 
> On Thursday, October 8, 2020 at 1:10:22 AM UTC+3 rcore...@gmail.com wrote:
> Jon's points probably sink this proposal. Go is a very different language, 
> and making it less self-consistent to solve some fraction of syntactic 
> readability is almost certainly not going to 

[go-nuts] Re: Reduced error handling noice

[David Skinner]

This looks like something I might have done. However, my preference would 
be to write a wrapper MustGetParameter receives string field, calls 
store.GetParameter(field), returns parameter or panics. 

You may then use
defer func() { globalErr = recover()} 
tenantID, err1 := MustGetParameter("TENANT_ID")
clientID, err2 := MustGetParameter("CLIENT_ID")
clientSecret, err3 := MustGetParameter("CLIENT_SECRET")

return connection{
tenantID,
clientID,
clientSecret,
}, globalErr

If an error can be handled, it should be handled, but if you are just 
cascading the reports of errors, use defer recover as a try and let the 
calling function handle it. Of course some panics really should be a panic 
so you might want to have your defer func check the panic error to see if 
it is expected or something that really is a panic.

When I do an API I may have a Doit and a MustDoit, one returns an error and 
the other panics. My way of keeping the code clean unless I can actually do 
something about the error.

On Wednesday, October 7, 2020 at 1:36:07 PM UTC-5 johan.ma...@dexyos.fr 
wrote:

> Hi, I'm looking for thoughts from some experienced go programmers on a 
> technique to reduce error handling verbosity. 
>
> The basic idea is to be optimistic over a few instructions, and then 
> combine many errors in to one. This gist and explains the idea (note the 
> absence of if err != nil {} )
>
> tenantID, err1 := store.GetParameter("TENANT_ID")
> clientID, err2 := store.GetParameter("CLIENT_ID")
> clientSecret, err3 := store.GetParameter("CLIENT_SECRET")
>
> globalErr := multierr.Combine(err1, err2, err3)
> return connection{
> tenantID,
> clientID,
> clientSecret,
> }, globalErr
>
> There's some more detail in a post 
> http://martinsson-johan.blogspot.com/2020/10/less-error-handling-noice-in-go.html.
>  
> I'm sure someone else has already proposed this, but I wasn't able to find 
> it. Grateful for pointers
>  
> While it seems sound to me I'm a very interested in what people from the 
> community thinks.
>
> Cheers
> Johan Martinsson
>
>

-- 
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/73e712c2-948b-459f-8c07-6e201a8f6454n%40googlegroups.com.

[go-nuts] Re: Should we check to see if G is on a P then decide to spin or sleep on mutex lock

[Uday Kiran Jonnala]

I meant "see if G is on an M"

On Wednesday, October 7, 2020 at 5:55:45 PM UTC-7 Uday Kiran Jonnala wrote:

> Just wondering if we can add additional condition below
>
> https://golang.org/src/runtime/lock_futex.go
>
> func lock2(l *mutex) {
>  gp := getg() 52  
> ...
>  // Try for lock, rescheduling. 
>  for i := 0; i < passive_spin; i++ {  
>
> We may need to improve this by stubbing the ownership information say M id 
> into
> lock, that way we can decide to spin or sleep if G is running on M 
> currently.
>
> Just a thought.
>
> Starting now on go runtime...thinking a loud here.
>
> Thanks & Regards,
> Uday Kiran
>

-- 
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/2d8d3d05-e522-45b2-9989-ae266794a34dn%40googlegroups.com.

[go-nuts] Should we check to see if G is on a P then decide to spin or sleep on mutex lock

[Uday Kiran Jonnala]

Just wondering if we can add additional condition below

https://golang.org/src/runtime/lock_futex.go

func lock2(l *mutex) {
 gp := getg() 52  
...
 // Try for lock, rescheduling. 
 for i := 0; i < passive_spin; i++ {  

We may need to improve this by stubbing the ownership information say M id 
into
lock, that way we can decide to spin or sleep if G is running on M 
currently.

Just a thought.

Starting now on go runtime...thinking a loud here.

Thanks & Regards,
Uday Kiran

-- 
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/75ff47d0-f708-4422-9017-bb2ab6e970d4n%40googlegroups.com.

Re: [go-nuts] Proposal to add Index operator methods

[Raanan Hadar]

So we respectfully disagree here, so the best thing I can do is add some 
quality arguments. I think this is an important discussion that might 
cement Go as a broad DSL in the sense that it does a lot of things 
exceptionally well, but this issue will remain a blind spot.

I fully understand the need to keep Go "pure and simple". Its the key to 
its success. But this is an important area where Go does not have enough 
features to be effective. Secondly, I think that solving this issue can be 
achieved while maintaining orthogonality and not hurting experience of the 
majority. Third, as I answered Jon, I think that looking at this proposal, 
or more generally, this problem, from the Go programmer's perspective, is 
like trying to optimize a local optima. Go programmers don't have much to 
gain from this. But from a global perspective that seeks to optimize 
software development as a whole, there's a huge benefit that is overlooked 
here. Go was not designed to cater the needs of the programmer but software 
engineering as an end to end process 
(https://talks.golang.org/2012/splash.article).

With regards to Python, I've detailed common examples in my proposal, where 
Python for numerical computing leaves a lot to be desired. Fundamental 
issues which Go solves by design and are not addressed effectively by 
putting the two together as you suggested. Secondly, I am not the only one 
saying that there is a real need for a better language than Python. To name 
two good examples: Yann LeCun said this last year: 
https://venturebeat.com/2019/02/18/facebooks-chief-ai-scientist-deep-learning-may-need-a-new-programming-language/
 
and Jeremy Howard, former president and chief scientist of Kaggle and the 
author of the fast.ai, strongly advocates that Python is not the way to go 
in long run: https://www.youtube.com/watch?v=c-KAf2g6YN4  


On Thursday, October 8, 2020 at 1:10:22 AM UTC+3 rcore...@gmail.com wrote:

> Jon's points probably sink this proposal. Go is a very different language, 
> and making it less self-consistent to solve some fraction of syntactic 
> readability is almost certainly not going to get over the very high 
> threshold for changing the language.
>
> If you're going to switch over to Go, you'll have to learn a LOT of new 
> concepts and change the way you approach things. In the end, it is better 
> that Go remain "pure and simple" -- the simpler it remains, the easier it 
> is for anyone to learn it, no matter where they are coming from.
>
> Another strategy, which I'm pursuing, is to support Python as a scripting 
> language on top of Go backend code that does all the heavy lifting. That is 
> how Python is used in most cases already, except with C / C++ backends. So, 
> keep Python Python, and keep Go Go, but allow people to interoperate more 
> easily. This way, people can get some exposure to the virtues of Go, and 
> maybe decide to switch over at some point..
>
> This tool makes it relatively easy: https://github.com/go-python/gopy 
> I've also written a GoToPy converter https://github.com/goki/gotopy (will 
> be moving over to go-python soon -- no time right now), so you can write 
> 'main' programs in Go, then easily convert them over to Python (Go -> 
> Python is very easy, the other way not so much), which provides a point of 
> departure for Python folks to start using your code..
>
> - Randy
>
> > On Oct 6, 2020, at 12:56 AM, Raanan Hadar  wrote:
> > 
> > Lets start with saying that I think this is a valid criticism. 
> > 
> > Although it does not solve things 100%, it does solve the heart of the 
> problem for me at least: 
> > There is a mixture of index operators with functional operators in the 
> syntax:
> > The [] operator gives the reader the 'where' context and the () gives 
> the reader the 'what' context. If you are using all your arguments via () 
> causes the readability problem. So while not having full operator 
> overloading, you still have to use .Add() instead of '+', the grammar is 
> now consistent and concise and separates the 'where' from the 'what'.
> > 
> > Also, please consider that different users have a different 'value 
> scale' to gain from this proposal:
> > To a gonum user, this proposal is about a 20% improvement and nothing to 
> run home about.
> > To a matlab/python programmer, this solves about 80% of their problems 
> and combining this with the other benefits of Go is enough to strongly 
> consider switching to Go.
> > 
> > Realistically, I don't think that I can convince the Go core dev team to 
> add full operator overloading and that is 
> > probably the only way to achieve what you are suggesting... if you have 
> another way to achieve this, I am open
> > In the end of the day, the question to ask is whether or not we 
> > are better off in implementing this.
> > On Tuesday, October 6, 2020 at 9:33:17 AM UTC+3 jonr...@gmail.com wrote:
> > i think this looks nice but realistically only cleans up v simple cases. 
> a lot of the 

Re: [go-nuts] Proposal to add Index operator methods

[Randall O'Reilly]

Jon's points probably sink this proposal.  Go is a very different language, and 
making it less self-consistent to solve some fraction of syntactic readability 
is almost certainly not going to get over the very high threshold for changing 
the language.

If you're going to switch over to Go, you'll have to learn a LOT of new 
concepts and change the way you approach things.  In the end, it is better that 
Go remain "pure and simple" -- the simpler it remains, the easier it is for 
anyone to learn it, no matter where they are coming from.

Another strategy, which I'm pursuing, is to support Python as a scripting 
language on top of Go backend code that does all the heavy lifting.  That is 
how Python is used in most cases already, except with C / C++ backends.  So, 
keep Python Python, and keep Go Go, but allow people to interoperate more 
easily.  This way, people can get some exposure to the virtues of Go, and maybe 
decide to switch over at some point..

This tool makes it relatively easy: https://github.com/go-python/gopy   I've 
also written a GoToPy converter https://github.com/goki/gotopy (will be moving 
over to go-python soon -- no time right now), so you can write 'main' programs 
in Go, then easily convert them over to Python (Go -> Python is very easy, the 
other way not so much), which provides a point of departure for Python folks to 
start using your code..

- Randy

> On Oct 6, 2020, at 12:56 AM, Raanan Hadar  wrote:
> 
> Lets start with saying that I think this is a valid criticism. 
> 
> Although it does not solve things 100%, it does solve the heart of the 
> problem for me at least: 
> There is a mixture of index operators with functional operators in the syntax:
> The [] operator gives the reader the 'where' context and the () gives the 
> reader the 'what' context. If you are using all your arguments via () causes 
> the readability problem. So while not having full operator overloading, you 
> still have to use .Add() instead of '+', the grammar is now consistent and 
> concise and separates the 'where' from the 'what'.
> 
> Also, please consider that different users have a different 'value scale' to 
> gain from this proposal:
> To a gonum user, this proposal is about a 20% improvement and nothing to run 
> home about.
> To a matlab/python programmer, this solves about 80% of their problems and 
> combining this with the other benefits of Go is enough to strongly consider 
> switching to Go.
> 
> Realistically, I don't think that I can convince the Go core dev team to add 
> full operator overloading and that is 
> probably the only way to achieve what you are suggesting... if you have 
> another way to achieve this, I am open
> In the end of the day, the question to ask is whether or not we 
> are better off in implementing this.
> On Tuesday, October 6, 2020 at 9:33:17 AM UTC+3 jonr...@gmail.com wrote:
> i think this looks nice but realistically only cleans up v simple cases.  a 
> lot of the very-verbose-and-not-so-elegant-looking multidimensional math 
> stuff looks "worse" than other languages because go doesn't have operator 
> overloading.  it is not clear to me this improves syntax too much in practice 
> on it's own.  (this is not a request to add operator overloading but merely 
> the non-controversial statement that operator overloading can help math-heavy 
> code look more "hand drawn" sometimes).
> 
> the gorgonia example is indicative of the issue: nil may be less 
> aesthetically pleasing than ":" (or not) but it's unlikely the surrounding 
> code looks anything like the math as expressed on paper by hand either.
> 
> gonum is quite convenient even with this...code that uses it can look a bit 
> more 1960s than other languages but it is simple and super-clear.  i like 
> that i am never (read: rarely) confused by () or , or [] etc characters in 
> go.  if you could find a way to cover more ground the change would look more 
> compelling to me.
> 
> On Mon, Oct 5, 2020 at 12:04 PM Raanan Hadar  wrote:
> It actually didn't change that much, I just applied your valuable feedback. 
> Thanks alot!
> 
> Its critical to communicate clearly.
> so I changed the before and after part of the proposal to be more 
> approachable to people who 
> are less familiar with numerical libraries in Go.
> 
> Its not a trivial proposal in that the main audience will probably use it in 
> a library and not in vanilla Go.
> But it was still a very valid point.
> 
> thanks again.
> 
> On Monday, October 5, 2020 at 3:19:02 AM UTC+3 jake...@gmail.com wrote:
> The examples I was looking at are gone now. That section has been completely 
> rewritten. So its kind of moot. Its possible that I was confusing the 
> 'before' and 'after' examples, since they were not clearly labeled. In any 
> case the rewritten version seems to make sense now. 
> 
> On Sunday, October 4, 2020 at 4:50:10 PM UTC-4 kortschak wrote:
> On Sun, 2020-10-04 at 09:06 -0700, jake...@gmail.com wrote: 
> > I stopped reading at 

Re: [go-nuts] Question on the generics proposal and arrays

[Markus Heukelom]

On Wed, Oct 7, 2020 at 9:12 PM Howard C. Shaw III 
wrote:

> You said:
>
>> I was trying around with arrays and generics because slices are more
>> complex to reason about than arrays. For example, I introduced bugs into my
>> code by not being fully aware of slices overwriting original data when you
>> append to them and the capacity is not set correctly. So, when writing
>> critical code it could be safer to avoid slices if possible for
>> this reason. Another example:
>>
>
> In my experience, you either have a fixed array size in mind to begin with
> (as in a fixed array size in a struct for padding or matching a fixed size
> C array) or you should be using a slice anyway.
>
> The trouble mostly comes when you keep the array around after making a
> slice of it. If you are  going to be doing *any* manipulation of a slice,
> abandoning the underlying array and only carrying around slices gets rid of
> most such errors. A slice already IS effectively an 'array, generic on
> size.'
>

Hm, abandoning the underlying array does not really help I think:

u := []byte{0, 1, 2, 3}
a := u[0:2]
b := u[2:]
u = nil  // abandon u
a = append(a, 4)
fmt.Println(b) // [4, 3]!! not intended

Should be:

u := []byte{0, 1, 2, 3}
a := u[0:2:2] // use correct capacity!
b := u[2:len(u)] // use correct capacity!
u = nil // abandon u
a = append(a, 4)
fmt.Println(b) // [2, 3], ok!

Btw, I am not saying fixed arrays are a solution for this of course and I
agree it is not a big problem in practice as otherwise slices are really
handy.




-- 
> 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/MF1UzRrx9mU/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/08fe15f5-dff1-4651-b824-86266b3ce50bn%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/CAMoB8rU4imEf5OdRi_0DXpH6y21r5kcw6UzXUPCz%3DQqpuwC3Hw%40mail.gmail.com.

Re: [go-nuts] Question on the generics proposal and arrays

[Howard C. Shaw III]

You said: 

> I was trying around with arrays and generics because slices are more 
> complex to reason about than arrays. For example, I introduced bugs into my 
> code by not being fully aware of slices overwriting original data when you 
> append to them and the capacity is not set correctly. So, when writing 
> critical code it could be safer to avoid slices if possible for 
> this reason. Another example:
>

In my experience, you either have a fixed array size in mind to begin with 
(as in a fixed array size in a struct for padding or matching a fixed size 
C array) or you should be using a slice anyway. 

The trouble mostly comes when you keep the array around after making a 
slice of it. If you are  going to be doing *any* manipulation of a slice, 
abandoning the underlying array and only carrying around slices gets rid of 
most such errors. A slice already IS effectively an 'array, generic on 
size.'

-- 
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/08fe15f5-dff1-4651-b824-86266b3ce50bn%40googlegroups.com.

[go-nuts] Reduced error handling noice

[Johan Martinsson]

Hi, I'm looking for thoughts from some experienced go programmers on a 
technique to reduce error handling verbosity. 

The basic idea is to be optimistic over a few instructions, and then 
combine many errors in to one. This gist and explains the idea (note the 
absence of if err != nil {} )

tenantID, err1 := store.GetParameter("TENANT_ID")
clientID, err2 := store.GetParameter("CLIENT_ID")
clientSecret, err3 := store.GetParameter("CLIENT_SECRET")

globalErr := multierr.Combine(err1, err2, err3)
return connection{
tenantID,
clientID,
clientSecret,
}, globalErr

There's some more detail in a post 
http://martinsson-johan.blogspot.com/2020/10/less-error-handling-noice-in-go.html.
 
I'm sure someone else has already proposed this, but I wasn't able to find 
it. Grateful for pointers
 
While it seems sound to me I'm a very interested in what people from the 
community thinks.

Cheers
Johan Martinsson

-- 
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/03d0ff66-3767-40a0-8552-4e124f1cc44bn%40googlegroups.com.

Re: [go-nuts] ECDSA signature verification

[Shobhit Srivastava]

Yeah the inclination is towards 512 curve only so need to optimise it.

Will check out the C library. Thanks



On Wed, 7 Oct 2020, 22:22 Marcin Romaszewicz,  wrote:

> secp256r1 has been hand optimized for performance, the others haven't.
>
> If performance there matters to you, it's actually faster to call out to C
> libraries to verify 384 and 512 bit curves.
>
> On Wed, Oct 7, 2020 at 9:27 AM Shobhit Srivastava 
> wrote:
>
>> Hi All
>>
>> I have tried to do the performance analysis for different curve in golang
>> and got below output:
>> for secp256r1 I got 28000 Signature verified per second
>> for secp384r1 I got 1600 Signature verified per second
>> for secp521r1 I got 700 Signature verified per second
>>
>> Is there something I did wrong or is this the usual results?
>>
>> Let me know if someone has done performance comparison.
>>
>> Best,
>> Shobhit
>>
>> --
>> 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/fdc14759-b995-43af-948d-cdb2201e4718n%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/CAHM18J0wyHQhiSfJdCwJTM93xQJ0n98CyhN%2BYWxczsKLYc-sMQ%40mail.gmail.com.

Re: [go-nuts] ECDSA signature verification

[Marcin Romaszewicz]

secp256r1 has been hand optimized for performance, the others haven't.

If performance there matters to you, it's actually faster to call out to C
libraries to verify 384 and 512 bit curves.

On Wed, Oct 7, 2020 at 9:27 AM Shobhit Srivastava 
wrote:

> Hi All
>
> I have tried to do the performance analysis for different curve in golang
> and got below output:
> for secp256r1 I got 28000 Signature verified per second
> for secp384r1 I got 1600 Signature verified per second
> for secp521r1 I got 700 Signature verified per second
>
> Is there something I did wrong or is this the usual results?
>
> Let me know if someone has done performance comparison.
>
> Best,
> Shobhit
>
> --
> 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/fdc14759-b995-43af-948d-cdb2201e4718n%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/CA%2Bv29Lu_jcEc9BN87mojgZVWxsvRM2VZydi05oKoxD39KfU-9Q%40mail.gmail.com.

[go-nuts] ECDSA signature verification

[Shobhit Srivastava]

Hi All 

I have tried to do the performance analysis for different curve in golang 
and got below output:
for secp256r1 I got 28000 Signature verified per second
for secp384r1 I got 1600 Signature verified per second  
for secp521r1 I got 700 Signature verified per second

Is there something I did wrong or is this the usual results?

Let me know if someone has done performance comparison.

Best,
Shobhit

-- 
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/fdc14759-b995-43af-948d-cdb2201e4718n%40googlegroups.com.

[go-nuts] Capture Outgoing Port for a HTTP Request

[ryan...@gmail.com]

Is it possible to capture the outgoing port for a given HTTP request?

I'm using a knockoff of ab that I wrote in go to send repeated requests to 
a given web service. Sometimes we get an error and I want to look at a 
packet trace of it. The problem is it's really hard to find one failed 
request in 1,000 in a tcp dump. If I can see the source port, that would 
help me narrow it down.

The code I'm doing is effectively this (forgive any typos, this is a quick 
& dirty recopy, not a cut & paste):

tlsConfig := {
InsecureSkipVerify: true,
}

transport := {
DisableKeepAlives: true,
TLSClientCOnfig: tlsCOnfig,
ResponseHeaderTimeout: time.Duration(headerTimeout) * time.Second,
}

client := {
Timeout: time.Duration(timeOut) * time.second,
Transport: transport,
}

response, err :=client.Get(*targetURL)// How can I capture the outgoing 
port from this?

-- 
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/4b26a0c8-120c-4eb5-8bcf-4b7784a8b615n%40googlegroups.com.

Fwd: [go-nuts] Question on the generics proposal and arrays

[Markus Heukelom]

On Tue, Oct 6, 2020 at 7:45 PM Ian Lance Taylor  wrote:

> On Tue, Oct 6, 2020 at 6:32 AM Markus Heukelom 
> wrote:
> >
> > It appears to me the current proposal does not allow you to write a
> function that sorts an array of any size:
> >
> > func SortArray[T comparable](array [??]T, less func(a, b T) bool) [??]T
> {}
> >
> > Is it correct that this is not possible? Or is this expressed
> differently?
> >
> > To clarify, I am seeking for something like:
> >
> > func SortArray[T comparable, int n](array [n]T, less func(a, b T) bool)
> [n]T {}
>
> You are correct that the current design draft does not provide any
> mechanism for writing code that is generic across the dimension of an
> array.  This is mentioned in the list at
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#omissions
> .
>

Thanks, I missed this sentence.

I don't think it would be hard to add later if it seems useful.
>
>
Thanks, this is good to know. Because arrays are simpler types than slices
(slices are built using arrays), it would indeed make sense to add this
support (or at least at some point). Otherwise wrt generics, arrays would
be sort of second class, so to speak :)

That said, I don't think your suggested SortArray function would be a good
> API.  In Go arrays are passed by value, so this would copy the

entire array into the function, sort it, and then copy the entire
> array out.  It is trivial to turn an array into a slice, by writing
> a[:], so it would be more natural in Go to write Sort(a[:], less),
> which would let the caller decide whether to make a copy or not

I agree. But if you need both the original and the sorted array, it could
make sense. It was just meant as an example though.

I was trying around with arrays and generics because slices are more
complex to reason about than arrays. For example, I introduced bugs into my
code by not being fully aware of slices overwriting original data when you
append to them and the capacity is not set correctly. So, when writing
critical code it could be safer to avoid slices if possible for
this reason. Another example:

type block[T interface{}] struct {
next *block[T]
used int
items [BLOCKSIZE]T
}

Of course, items can be a slice here. But an array is simpler, and maybe
block is part of a container that is an alternative to slices. However,
BLOCKSIZE would be logical to make configurable and then you need to be
able to write methods that deal with  [BLOCKSIZE]T, or at least  [.]T,
where [.]T means "an array of T of any size".



> Here's two other examples that come to mind:
> >
> > type Number {types ...}
> > func DotProduct[T Number, int n](a, b [n]T) T {} // n can be any integer
> > func MultMatVec[T Number, rows, cols int](m [rows][cols]T, v [cols]T)
> [rows]T {}
>
> Agreed.
>
> 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/CAMoB8rVWt%2BmpfHU%3D1RwdJngGji%2BwM-u9JVci0LcmyEgZnKBgOg%40mail.gmail.com.

Re: [go-nuts] Can ".." occur in golang source?

[Brian Candler]

On Wednesday, 7 October 2020 09:31:55 UTC+1, Ryan Keppel wrote:
>
> I meant this code: 
> https://golang.org/src/cmd/compile/internal/syntax/scanner.go#L187 .
>

That code says:

- dot followed by a decimal is a number
- dot followed by dot followed by dot is a _DotDotDot (ellipsis)
- otherwise, it's just a _Dot

-- 
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/e299a873-4978-42de-b790-6b43a2b05137o%40googlegroups.com.

[go-nuts] Re: zero maps rationale

[Brian Candler]

On Wednesday, 7 October 2020 08:05:39 UTC+1, Amnon wrote:
>
> Go generally ensures that zero values are useful.
>
> So a zero slice allows us to append to it, without having to do any 
> special initialization.
>
>
Not exactly.  Appending to a slice always creates a *new* slice value:

s2 := append(s1, v)

(Aside: the new slice may or may not share the same backing store as the 
original slice, depending on whether s1's backing is suitable or not. But 
s2 is always a new *value*)

It becomes clear when you realise that a slice value is really a hidden 
struct, in pseudo-code something like:

struct {
backing *T
cap int
len int
}

The zero slice value is this struct initialized to all zeros.  This gives a 
null pointer (i.e. no backing store), and a zero cap and len.

There's very little you can do with this value, except determine that its 
length is zero.

So why are maps different? Why is it necessary to make a map, before it can 
> be assigned to?
> Is there any use case where a zero map which can not be assigned to is 
> useful?
>

Just like the zero slice, the zero map can be read from, and it returns 
len() of zero.  Reading any key from it will return zero value.

Like the slice, the map is also a struct which contains a pointer. However 
for simplicity and efficiency reasons, you add to a map by mutating it, not 
by creating a new map.  This means that the map must have been initialized, 
so that its internal pointer points to a valid data structure, before you 
can update it.

If you want appending to a map to work the same way as appending to a 
slice, you can wrap it yourself easily enough:
https://play.golang.org/p/6Q9EtMVUsea

-- 
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/a1d29afc-4307-4b32-b4e4-431fc5d965cao%40googlegroups.com.

Re: [go-nuts] Can ".." occur in golang source?

[Jesper Louis Andersen]

On Wed, Oct 7, 2020 at 10:29 AM Ryan Keppel  wrote:

> Yes, I mean that code section. I did a quick test and two floats tokenizes
> just fine (2..5 tokenizes to "2." and ".5")--it doesn't invoke the
> described code. I don't think Go in practice would allow two dot tokens in
> a row. Go's parser is very loose ("1 + 10 = 20" isn't a syntax error) and I
> don't see it allowing that.
>
>
That code section scans for token.ELLIPSIS, i.e., '...'.

The scanner has ch := s.ch already from the "outer" switch. When you hit
the default case, you run s.next() which advances the scanner. Now, s.ch
points to the second '.' and the s.peek() will have us peek at the third
'.'. The calls to s.next() twice advances us beyond that, and we have an
ellipsis, i.e., '...'

Lines of interest, though they might move: 791, 809, 837-844 (The future
reader might be interested in knowing this was around go version 1.15.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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAGrdgiV_K8ufXR8JMm%3DSy9bL2iuAuJOtxnpA02jEMV3bVs9%2BTA%40mail.gmail.com.

Re: [go-nuts] Can ".." occur in golang source?

[Ryan Keppel]

I meant this 
code: https://golang.org/src/cmd/compile/internal/syntax/scanner.go#L187 .

On Wednesday, October 7, 2020 at 1:29:24 AM UTC-7 Ryan Keppel wrote:

> Yes, I mean that code section. I did a quick test and two floats tokenizes 
> just fine (2..5 tokenizes to "2." and ".5")--it doesn't invoke the 
> described code. I don't think Go in practice would allow two dot tokens in 
> a row. Go's parser is very loose ("1 + 10 = 20" isn't a syntax error) and I 
> don't see it allowing that.
>
> On Wednesday, October 7, 2020 at 1:04:21 AM UTC-7 Jan Mercl wrote:
>
>> On Wed, Oct 7, 2020 at 9:23 AM Ryan Keppel  wrote:
>>
>> > In the current Golang
>>
>> The name is Go. There's no Golang programming language.
>>
>> > implementation of scanning, there's some extra code to handle ".." in 
>> the source (as two dot tokens).
>>
>> Do you mean this? https://golang.org/src/go/scanner/scanner.go#L837
>>
>> > Would this ever happen in practice?
>>
>> Sure, why not? Scanner will happily scan two consecutive dot tokens,
>> that's its job.
>>
>> > Two floats together?
>>
>> No. This seems to conflate what a scanner is for with the grammar of
>> the language. Package scanner can handle sources like `for package if
>> not break ..123..` just fine. The language specification not so much.
>> But in Go, as in many other languages, the lexical and syntax grammars
>> are two different things, even though the latter builds upon the
>> former.
>>
>

-- 
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/e451452f-230c-4c33-ba86-6d6125c12d73n%40googlegroups.com.

Re: [go-nuts] Can ".." occur in golang source?

[Ryan Keppel]

Yes, I mean that code section. I did a quick test and two floats tokenizes 
just fine (2..5 tokenizes to "2." and ".5")--it doesn't invoke the 
described code. I don't think Go in practice would allow two dot tokens in 
a row. Go's parser is very loose ("1 + 10 = 20" isn't a syntax error) and I 
don't see it allowing that.

On Wednesday, October 7, 2020 at 1:04:21 AM UTC-7 Jan Mercl wrote:

> On Wed, Oct 7, 2020 at 9:23 AM Ryan Keppel  wrote:
>
> > In the current Golang
>
> The name is Go. There's no Golang programming language.
>
> > implementation of scanning, there's some extra code to handle ".." in 
> the source (as two dot tokens).
>
> Do you mean this? https://golang.org/src/go/scanner/scanner.go#L837
>
> > Would this ever happen in practice?
>
> Sure, why not? Scanner will happily scan two consecutive dot tokens,
> that's its job.
>
> > Two floats together?
>
> No. This seems to conflate what a scanner is for with the grammar of
> the language. Package scanner can handle sources like `for package if
> not break ..123..` just fine. The language specification not so much.
> But in Go, as in many other languages, the lexical and syntax grammars
> are two different things, even though the latter builds upon the
> former.
>

-- 
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/aa2a6d6a-2293-4984-9632-0e9c7237ffaen%40googlegroups.com.

Re: [go-nuts] Can ".." occur in golang source?

[Jan Mercl]

On Wed, Oct 7, 2020 at 9:23 AM Ryan Keppel  wrote:

> In the current Golang

The name is Go. There's no Golang programming language.

> implementation of scanning, there's some extra code to handle ".." in the 
> source (as two dot tokens).

Do you mean this? https://golang.org/src/go/scanner/scanner.go#L837

> Would this ever happen in practice?

Sure, why not? Scanner will happily scan two consecutive dot tokens,
that's its job.

> Two floats together?

No. This seems to conflate what a scanner is for with the grammar of
the language. Package scanner can handle sources like `for package if
not break ..123..` just fine. The language specification not so much.
But in Go, as in many other languages, the lexical and syntax grammars
are two different things, even though the latter builds upon the
former.

-- 
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-WFkTPgUJO93wLcgGqm5fOc1L9NKR%2BPDExBctND6F%2BAog%40mail.gmail.com.

[go-nuts] Can ".." occur in golang source?

[Ryan Keppel]

In the current Golang implementation of scanning, there's some extra code 
to handle ".." in the source (as two dot tokens). Would this ever happen in 
practice? Two floats together?

-- 
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/a4d116f9-edb4-4a2c-9050-75d1aca80b5en%40googlegroups.com.

Re: [go-nuts] zero maps rationale

['Axel Wagner' via golang-nuts]

Hi,

this has been discussed many times, e.g.
https://groups.google.com/g/golang-nuts/c/5_8E9OblIho/m/b9O038mzBQAJ
In short: The semantics of maps require them to be pointer-shaped.
Currently, all zero values are a sequence of zero bytes (making it very
cheap to initialize to them). That means the zero value of maps can't be
made useful in that manner. It's unfortunate, but seems necessary.

On Wed, Oct 7, 2020 at 9:06 AM Amnon  wrote:

> Go generally ensures that zero values are useful.
>
> So a zero slice allows us to append to it, without having to do any
> special initialization.
>
> This approach also extends to the standard library.
>
> sync.Mutexs are unlocked and usable in the zero state.
>
> Even zero sync.Maps ready for use.
>
> So why are maps different? Why is it necessary to make a map, before it
> can be assigned to?
> Is there any use case where a zero map which can not be assigned to is
> useful?
>
> --
> 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/14e25f79-8fab-4cec-8c00-fedd26488014n%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/CAEkBMfGu4ax4U%2BUbGtuTfe7Tu1zsZZs_rySnn0Bgrt83KcyqUw%40mail.gmail.com.

[go-nuts] zero maps rationale

[Amnon]

Go generally ensures that zero values are useful.

So a zero slice allows us to append to it, without having to do any special 
initialization.

This approach also extends to the standard library.

sync.Mutexs are unlocked and usable in the zero state.

Even zero sync.Maps ready for use.

So why are maps different? Why is it necessary to make a map, before it can 
be assigned to?
Is there any use case where a zero map which can not be assigned to is 
useful?

-- 
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/14e25f79-8fab-4cec-8c00-fedd26488014n%40googlegroups.com.