[go-nuts] Will there be something like "net/quic" in the future?

[ran...@gmail.com]

Hello people :D

I just want to pop up to ask whether or not there will be a builtin package 
that implements QUIC for Go.

As you may have already heard, the standardization for QUIC is almost done, 
many people are rushing to implement the protocol for their own product.

Since more and more people is expected to use QUIC in the future, it could 
be beneficial to include it as part of the Go standard package, as doing so 
not only could provide a way for server developers to implement QUIC 
servers/client with ease, but it could also help the net/http implement to 
their QUIC transport for both it's server and client.

So maybe consider it?

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/23681d47-14e9-4d48-9d3b-35a96f3176cdn%40googlegroups.com.

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

[Raanan Hadar]

So the first paragraph in my answer to Jon addresses this. But I think I 
could have been clearer: I think 80% of the readability problem is 
addressed by index operator methods, which is the critical part. Full 
operator overloading is nice to have in my opinion and I argue people will 
gladly live without it given all the other benefits Go brings to the table 
in software engineering. I think its a very similar approach to what Go did 
with pointers: Is full pointer arithmetic beneficial? yes, but it would no 
longer be in the spirit of Go.

I think that using languages such as Matlab and Python as a starting point, 
or "prototyping languages" is becoming less and less relevant today. This 
might have been the way we developed algorithms ten years ago but today its 
just like any software development. The reality many data scientists and 
engineers face today is that data pipelines are constantly changing and 
increasing in complexity. They need to be maintainable and allow for quick 
iteration, integration and deployment. These are the qualities that Go 
excels at. A language that can effectively achieve a prototype in 80% the 
syntax efficiency but can sustain quality over time  is much more important 
than having the richest syntax possible. Another point is that even while 
in the "prototyping" phase, big data challenges which data scientist face 
today, unlike ten years ago, will require the data scientist to do some 
heavy lifting to get efficient compute, network and IO to get that initial 
result. So in many cases the "prototype" is often a complex pipeline that 
is deployed in k8s for example. 

I think that a Go-Python integration is excellent but as I noted, it leaves 
a lot to be desired. A lot has been written about the "infinite loop of 
sadness" (here is a good link: 
https://medium.com/pachyderm-data/sustainable-machine-learning-workflows-8c617dd5506d).
 
I think this is a big problem with companies like Google having an 
excellent understanding of challenges of sustaining data pipelines at 
scale. Its a lot of what they do in their day to day. This is why, I think 
the synergy in a single language will be amazing.

As for Julia, I was also excited when I first learned about it and I hope I 
am not offending anyone using Julia here. Because on paper its marketed as 
the killer language for this, but Julia has two big problems (I sample 
Julia regularly):
1. Julia is nowhere near ready. Julia has a few more years before it gets 
its basics down. I think it has made a lot of progress in the last few 
years but someone trying Julia out in 2020 is guaranteed to hit some really 
annoying hurdles from day one. I'll give you a trivial example, lets say 
you want an IDE for Julia. Your best bet today is probably a text editor 
like vim or emacs. You have JUNO for atom which is nice but no longer 
developed or the vscode IDE, which might be amazing in a few years but is 
far from stable (https://github.com/julia-vscode/julia-vscode/issues). And 
this is just one critical issue out of many.
2. My second issue with Julia is more troublesome because unlike the first, 
I don't think it will ever be solved. Julia is a language that was designed 
to be very rich syntax and feature wise. But its toolchain was completely 
neglected. Go has an amazing toolchain, its not the sexiest part of the 
language, but its critical and it was designed to encourage good software 
engineering. As Rob Pike said: "Although tools like these are rarely 
mentioned in the context of language design, they are an integral part of a 
language's ecosystem and the fact that Go was designed with tooling in mind 
has a huge effect on the development of the language, its libraries, and 
its community". Julia has poor package management and tooling which make it 
a pain to deploy in production compared to Go.

In summary, If Go were to implement this, I really believe that it will run 
circles around Julia even in a few years from now when it reaches puberty. 
Because Go is a better language when it comes to software engineering.
On Thursday, October 8, 2020 at 7:46:16 AM UTC+3 rcore...@gmail.com wrote:

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

Re: [go-nuts] ECDSA signature verification

[Shobhit Srivastava]

Hey Marcin

Can you give me the pointer on C library and if can be used in Cgo .

Thanks

On Wed, 7 Oct 2020, 22:27 Shobhit Srivastava,  wrote:

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

[go-nuts] in "_ = debug && mylog.Infof("%s %d", str, n)", will the mylog.Infof call be always not executed if variable debug is false?

[tapi...@gmail.com]

.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7e959192-6844-4ac7-8757-6ceaaa81d87bn%40googlegroups.com.

Re: [go-nuts] ECDSA signature verification

[Marcin Romaszewicz]

My issue was slightly different than yours, in that I was burning way too
much CPU verifying 384 bit client certificates for TLS. The solution was to
have nginx do TLS termination, and proxy decrypted traffic to my Go server,
rather than doing TLS termination in Go.

The first place I would start looking is either the LibreSSL or OpenSSL
libraries. LibreSSL is a cleanup of OpenSSL, which has grown messy over the
years. Both of these contain a crypto library which does what you want.
Here is what it looks like in LibreSSL:
https://man.openbsd.org/ECDSA_SIG_new.3

-- Marcin

On Thu, Oct 8, 2020 at 2:30 AM Shobhit Srivastava 
wrote:

> Hey Marcin
>
> Can you give me the pointer on C library and if can be used in Cgo .
>
> Thanks
>
> On Wed, 7 Oct 2020, 22:27 Shobhit Srivastava, 
> wrote:
>
>> 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/CA%2Bv29Lsf7yRFewPnGX%2BTKKpThH6f_vO-%3DuDopzThDAqKsrRpVQ%40mail.gmail.com.

[go-nuts] Re: in "_ = debug && mylog.Infof("%s %d", str, n)", will the mylog.Infof call be always not executed if variable debug is false?

[tapi...@gmail.com]

It looks the answer should be yes, as Go spec says:

   Logical operators apply to boolean 
 values and yield a result of 
the same type as the operands. The right operand is evaluated 
conditionally. 

Is my understanding right?



On Thursday, October 8, 2020 at 10:58:48 AM UTC-4 tapi...@gmail.com wrote:

>
> .

-- 
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/8d564e38-250c-4a31-a706-7be82f6ac61cn%40googlegroups.com.

Re: [go-nuts] ECDSA signature verification

[Shobhit Srivastava]

Thanks for the detailed explanation for your issue.
Thanks for the pointers for the library. Just a quick question, do you
think calling C library from Go can give great results for 521 curve.



On Thu, 8 Oct 2020, 21:03 Marcin Romaszewicz,  wrote:

> My issue was slightly different than yours, in that I was burning way too
> much CPU verifying 384 bit client certificates for TLS. The solution was to
> have nginx do TLS termination, and proxy decrypted traffic to my Go server,
> rather than doing TLS termination in Go.
>
> The first place I would start looking is either the LibreSSL or OpenSSL
> libraries. LibreSSL is a cleanup of OpenSSL, which has grown messy over the
> years. Both of these contain a crypto library which does what you want.
> Here is what it looks like in LibreSSL:
> https://man.openbsd.org/ECDSA_SIG_new.3
>
> -- Marcin
>
> On Thu, Oct 8, 2020 at 2:30 AM Shobhit Srivastava 
> wrote:
>
>> Hey Marcin
>>
>> Can you give me the pointer on C library and if can be used in Cgo .
>>
>> Thanks
>>
>> On Wed, 7 Oct 2020, 22:27 Shobhit Srivastava, 
>> wrote:
>>
>>> 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 <
 simplysh...@gmail.com> 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/CAHM18J3DxRRv07A23cHfwsgCh%3DRADPrYEFjy6aNehzuH_UKd8w%40mail.gmail.com.

Re: [go-nuts] ECDSA signature verification

[Marcin Romaszewicz]

Yes, in my experience, the C SSL libraries are much faster than Go's
implementation on curves P384 and P521, however, Go's tuned implementation
of P256 curves is comparable to OpenSSL performance (
https://golang.org/src/crypto/elliptic/). If you look in the directory I
linked, you'll see that it has assembly language implementations of the
P256 curve.

Practically, there isn't much reason today to use the P384 and P521 curves.
The security provided by P256 is very good, not known to be crackable
today, and it's a widely supported curve. P384 is reasonably well
supported, but not as widely, and P521 isn't well supported at all, since
it's not in the NSA Suite B crypto recommendations, which drive many crypto
standards.

-- Marcin


On Thu, Oct 8, 2020 at 8:40 AM Shobhit Srivastava 
wrote:

> Thanks for the detailed explanation for your issue.
> Thanks for the pointers for the library. Just a quick question, do you
> think calling C library from Go can give great results for 521 curve.
>
>
>
> On Thu, 8 Oct 2020, 21:03 Marcin Romaszewicz,  wrote:
>
>> My issue was slightly different than yours, in that I was burning way too
>> much CPU verifying 384 bit client certificates for TLS. The solution was to
>> have nginx do TLS termination, and proxy decrypted traffic to my Go server,
>> rather than doing TLS termination in Go.
>>
>> The first place I would start looking is either the LibreSSL or OpenSSL
>> libraries. LibreSSL is a cleanup of OpenSSL, which has grown messy over the
>> years. Both of these contain a crypto library which does what you want.
>> Here is what it looks like in LibreSSL:
>> https://man.openbsd.org/ECDSA_SIG_new.3
>>
>> -- Marcin
>>
>> On Thu, Oct 8, 2020 at 2:30 AM Shobhit Srivastava 
>> wrote:
>>
>>> Hey Marcin
>>>
>>> Can you give me the pointer on C library and if can be used in Cgo .
>>>
>>> Thanks
>>>
>>> On Wed, 7 Oct 2020, 22:27 Shobhit Srivastava, 
>>> wrote:
>>>
 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 <
> simplysh...@gmail.com> 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%2Bv29LuZjb5Y1xTMd58t97dAo8fFuk7iwt7Niz%2B4_V-BiUsQ8A%40mail.gmail.com.

Re: [go-nuts] ECDSA signature verification

[Shobhit Srivastava]

Thank you Marcin for your response.
It is really helpful.


On Thu, 8 Oct 2020, 21:52 Marcin Romaszewicz,  wrote:

> Yes, in my experience, the C SSL libraries are much faster than Go's
> implementation on curves P384 and P521, however, Go's tuned implementation
> of P256 curves is comparable to OpenSSL performance (
> https://golang.org/src/crypto/elliptic/). If you look in the directory I
> linked, you'll see that it has assembly language implementations of the
> P256 curve.
>
> Practically, there isn't much reason today to use the P384 and P521
> curves. The security provided by P256 is very good, not known to be
> crackable today, and it's a widely supported curve. P384 is reasonably well
> supported, but not as widely, and P521 isn't well supported at all, since
> it's not in the NSA Suite B crypto recommendations, which drive many crypto
> standards.
>
> -- Marcin
>
>
> On Thu, Oct 8, 2020 at 8:40 AM Shobhit Srivastava 
> wrote:
>
>> Thanks for the detailed explanation for your issue.
>> Thanks for the pointers for the library. Just a quick question, do you
>> think calling C library from Go can give great results for 521 curve.
>>
>>
>>
>> On Thu, 8 Oct 2020, 21:03 Marcin Romaszewicz,  wrote:
>>
>>> My issue was slightly different than yours, in that I was burning way
>>> too much CPU verifying 384 bit client certificates for TLS. The solution
>>> was to have nginx do TLS termination, and proxy decrypted traffic to my Go
>>> server, rather than doing TLS termination in Go.
>>>
>>> The first place I would start looking is either the LibreSSL or OpenSSL
>>> libraries. LibreSSL is a cleanup of OpenSSL, which has grown messy over the
>>> years. Both of these contain a crypto library which does what you want.
>>> Here is what it looks like in LibreSSL:
>>> https://man.openbsd.org/ECDSA_SIG_new.3
>>>
>>> -- Marcin
>>>
>>> On Thu, Oct 8, 2020 at 2:30 AM Shobhit Srivastava 
>>> wrote:
>>>
 Hey Marcin

 Can you give me the pointer on C library and if can be used in Cgo .

 Thanks

 On Wed, 7 Oct 2020, 22:27 Shobhit Srivastava, 
 wrote:

> 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 <
>> simplysh...@gmail.com> 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/CAHM18J2i76bTrNoUKu_zbsvxDcNKaDaPkXe9%3DQ9kXp5y1KuHOg%40mail.gmail.com.

[go-nuts] Re: Will there be something like "net/quic" in the future?

[Amnon]

You can try https://github.com/lucas-clemente/quic-go

You asked specifically about a builtin package i.e. a package in the 
standard library.
But I am not sure what advantages locating new protocols into the standard 
library 
would bring.

On Thursday, 8 October 2020 at 09:00:20 UTC+1 ran...@gmail.com wrote:

> Hello people :D
>
> I just want to pop up to ask whether or not there will be a builtin 
> package that implements QUIC for Go.
>
> As you may have already heard, the standardization for QUIC is almost 
> done, many people are rushing to implement the protocol for their own 
> product.
>
> Since more and more people is expected to use QUIC in the future, it could 
> be beneficial to include it as part of the Go standard package, as doing so 
> not only could provide a way for server developers to implement QUIC 
> servers/client with ease, but it could also help the net/http implement to 
> their QUIC transport for both it's server and client.
>
> So maybe consider it?
>
> 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/9cf1b1b1-3950-4a4b-9bf1-9b36f96cc874n%40googlegroups.com.

[go-nuts] Re: Will there be something like "net/quic" in the future?

[Amnon]

Also worth watching the talk by the author 
https://www.youtube.com/watch?v=BvpRBdWwecU&ab_channel=dotconferences

On Thursday, 8 October 2020 at 17:36:12 UTC+1 Amnon wrote:

> You can try https://github.com/lucas-clemente/quic-go
>
> You asked specifically about a builtin package i.e. a package in the 
> standard library.
> But I am not sure what advantages locating new protocols into the standard 
> library 
> would bring.
>
> On Thursday, 8 October 2020 at 09:00:20 UTC+1 ran...@gmail.com wrote:
>
>> Hello people :D
>>
>> I just want to pop up to ask whether or not there will be a builtin 
>> package that implements QUIC for Go.
>>
>> As you may have already heard, the standardization for QUIC is almost 
>> done, many people are rushing to implement the protocol for their own 
>> product.
>>
>> Since more and more people is expected to use QUIC in the future, it 
>> could be beneficial to include it as part of the Go standard package, as 
>> doing so not only could provide a way for server developers to implement 
>> QUIC servers/client with ease, but it could also help the net/http 
>> implement to their QUIC transport for both it's server and client.
>>
>> So maybe consider it?
>>
>> 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/77e07e31-352b-44ac-b9da-b0929f78fca8n%40googlegroups.com.

Re: [go-nuts] Re: Will there be something like "net/quic" in the future?

['Axel Wagner' via golang-nuts]

I think part of that has been answered: It allows using it with net/http.

On Thu, Oct 8, 2020 at 6:37 PM Amnon  wrote:

> You can try https://github.com/lucas-clemente/quic-go
>
> You asked specifically about a builtin package i.e. a package in the
> standard library.
> But I am not sure what advantages locating new protocols into the standard
> library
> would bring.
>
> On Thursday, 8 October 2020 at 09:00:20 UTC+1 ran...@gmail.com wrote:
>
>> Hello people :D
>>
>> I just want to pop up to ask whether or not there will be a builtin
>> package that implements QUIC for Go.
>>
>> As you may have already heard, the standardization for QUIC is almost
>> done, many people are rushing to implement the protocol for their own
>> product.
>>
>> Since more and more people is expected to use QUIC in the future, it
>> could be beneficial to include it as part of the Go standard package, as
>> doing so not only could provide a way for server developers to implement
>> QUIC servers/client with ease, but it could also help the net/http
>> implement to their QUIC transport for both it's server and client.
>>
>> So maybe consider it?
>>
>> 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/9cf1b1b1-3950-4a4b-9bf1-9b36f96cc874n%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/CAEkBMfHAsTBbJM-iXWk9%2BnGYXSSz7Wkn%3Dtk4fsbxKu_yqP2o-g%40mail.gmail.com.

[go-nuts] Re: Reduced error handling noice

[Johan Martinsson]

Indeed I learned this from https://blog.golang.org/defer-panic-and-recover 
and they mention this is done in the json module. And I couldn't adhere 
more. It's basically the same as try-catch from other languages. 

Doing this systematically in a Rest server for errors of type 502, 400, 404 
(in the sens route exists but not the resource with the given id) etc is 
still considered a good thing by go programmers?

On Thursday, October 8, 2020 at 5:18:11 AM UTC+2 skinne...@gmail.com wrote:

> 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/2254efb0-be1d-4e05-bbad-4602317ba078n%40googlegroups.com.

Re: [go-nuts] Re: Will there be something like "net/quic" in the future?

[Amnon]

But quic-go can be used with net/http

Just call http3.ListenAndServeQUIC instead of http.ListenAndServeTLS
and all your handlers should just work.

QUIC is still evolving, and putting it inside the Go standard library means 
that 
it would be bound by the Go 1 compatibility promise, effectively freezing 
its behaviour.
Having it in the standard library would also tie it to Go's six-monthly 
release cycle,
(whereas quic-go seems to get released around once a month).

- amnon


On Thursday, 8 October 2020 at 17:56:09 UTC+1 axel.wa...@googlemail.com 
wrote:

> I think part of that has been answered: It allows using it with net/http.
>
> On Thu, Oct 8, 2020 at 6:37 PM Amnon  wrote:
>
>> You can try https://github.com/lucas-clemente/quic-go
>>
>> You asked specifically about a builtin package i.e. a package in the 
>> standard library.
>> But I am not sure what advantages locating new protocols into the 
>> standard library 
>> would bring.
>>
>> On Thursday, 8 October 2020 at 09:00:20 UTC+1 ran...@gmail.com wrote:
>>
>>> Hello people :D
>>>
>>> I just want to pop up to ask whether or not there will be a builtin 
>>> package that implements QUIC for Go.
>>>
>>> As you may have already heard, the standardization for QUIC is almost 
>>> done, many people are rushing to implement the protocol for their own 
>>> product.
>>>
>>> Since more and more people is expected to use QUIC in the future, it 
>>> could be beneficial to include it as part of the Go standard package, as 
>>> doing so not only could provide a way for server developers to implement 
>>> QUIC servers/client with ease, but it could also help the net/http 
>>> implement to their QUIC transport for both it's server and client.
>>>
>>> So maybe consider it?
>>>
>>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/9cf1b1b1-3950-4a4b-9bf1-9b36f96cc874n%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/42e27b8d-58ee-4d1b-ae1d-069de7d65614n%40googlegroups.com.

Re: [go-nuts] Re: Will there be something like "net/quic" in the future?

['Axel Wagner' via golang-nuts]

On Thu, Oct 8, 2020 at 7:09 PM Amnon  wrote:

> But quic-go can be used with net/http
>
> Just call http3.ListenAndServeQUIC instead of http.ListenAndServeTLS
> and all your handlers should just work.
>

That would mean you are *not* using `net/http`. In particular, it means
code would need to explicitly import http3 to use it.

QUIC is still evolving, and putting it inside the Go standard library means
> that
> it would be bound by the Go 1 compatibility promise, effectively freezing
> its behaviour.
> Having it in the standard library would also tie it to Go's six-monthly
> release cycle,
> (whereas quic-go seems to get released around once a month).
>

OP wrote "as you may have already heard, the standardization for QUIC is
almost done", implying this was a question about a future, stable spec for
QUIC.



>
> - amnon
>
>
> On Thursday, 8 October 2020 at 17:56:09 UTC+1 axel.wa...@googlemail.com
> wrote:
>
>> I think part of that has been answered: It allows using it with net/http.
>>
>> On Thu, Oct 8, 2020 at 6:37 PM Amnon  wrote:
>>
>>> You can try https://github.com/lucas-clemente/quic-go
>>>
>>> You asked specifically about a builtin package i.e. a package in the
>>> standard library.
>>> But I am not sure what advantages locating new protocols into the
>>> standard library
>>> would bring.
>>>
>>> On Thursday, 8 October 2020 at 09:00:20 UTC+1 ran...@gmail.com wrote:
>>>
 Hello people :D

 I just want to pop up to ask whether or not there will be a builtin
 package that implements QUIC for Go.

 As you may have already heard, the standardization for QUIC is almost
 done, many people are rushing to implement the protocol for their own
 product.

 Since more and more people is expected to use QUIC in the future, it
 could be beneficial to include it as part of the Go standard package, as
 doing so not only could provide a way for server developers to implement
 QUIC servers/client with ease, but it could also help the net/http
 implement to their QUIC transport for both it's server and client.

 So maybe consider it?

 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...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/9cf1b1b1-3950-4a4b-9bf1-9b36f96cc874n%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/42e27b8d-58ee-4d1b-ae1d-069de7d65614n%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/CAEkBMfFOABT9hGUBw7%3DDUOP9u%3D0B_7PVdjf6U3PAjfzUYPyXbw%40mail.gmail.com.

Re: [go-nuts] Re: in "_ = debug && mylog.Infof("%s %d", str, n)", will the mylog.Infof call be always not executed if variable debug is false?

[Jan Mercl]

On Thu, Oct 8, 2020, 17:40 tapi...@gmail.com  wrote:

> It looks the answer should be yes, as Go spec says:
>
>Logical operators apply to boolean
>  values and yield a result of
> the same type as the operands. The right operand is evaluated
> conditionally.
>
> Is my understanding right?
>

Yes.



>
>
> On Thursday, October 8, 2020 at 10:58:48 AM UTC-4 tapi...@gmail.com wrote:
>
>>
>> .
>
> --
> 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/8d564e38-250c-4a31-a706-7be82f6ac61cn%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/CAA40n-VsA-VBxTDEwEesV240%3DZ7do4H6S9K-W7_zvS7sh3LYtg%40mail.gmail.com.

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

[urji...@gmail.com]

Hi Ryan,

You can get it via httptrace (https://blog.golang.org/http-tracing)

Example:
  req, _ := http.NewRequest("GET", "http://example.com";, nil)
  trace := &httptrace.ClientTrace{
  GotConn: func(connInfo httptrace.GotConnInfo) {
  fmt.Printf("Got Conn: %s\n", 
connInfo.Conn.LocalAddr().String()) <- This has the 
local outgoing port
  },
   }
  req = req.WithContext(httptrace.WithClientTrace(req.Context(), trace))
  if _, err := http.DefaultTransport.RoundTrip(req); err != nil {
 log.Fatal(err)
  }


On Wednesday, October 7, 2020 at 9:09:54 AM UTC-7 ryan...@gmail.com wrote:

> 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 := &tls.Config{
> InsecureSkipVerify: true,
> }
>
> transport := &http.Transport{
> DisableKeepAlives: true,
> TLSClientCOnfig: tlsCOnfig,
> ResponseHeaderTimeout: time.Duration(headerTimeout) * time.Second,
> }
>
> client := &http.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/ae1b90e8-8562-47d1-92c8-801551f7a257n%40googlegroups.com.

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

[ryan...@gmail.com]

That was exactly what I was looking for. Thank you!

On Thursday, October 8, 2020 at 1:12:39 PM UTC-5 urji...@gmail.com wrote:

> Hi Ryan,
>
> You can get it via httptrace (https://blog.golang.org/http-tracing)
>
> Example:
>   req, _ := http.NewRequest("GET", "http://example.com";, nil)
>   trace := &httptrace.ClientTrace{
>   GotConn: func(connInfo httptrace.GotConnInfo) {
>   fmt.Printf("Got Conn: %s\n", 
> connInfo.Conn.LocalAddr().String()) <- This has the 
> local outgoing port
>   },
>}
>   req = req.WithContext(httptrace.WithClientTrace(req.Context(), trace))
>   if _, err := http.DefaultTransport.RoundTrip(req); err != nil {
>  log.Fatal(err)
>   }
>
>
> On Wednesday, October 7, 2020 at 9:09:54 AM UTC-7 ryan...@gmail.com wrote:
>
>> 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 := &tls.Config{
>> InsecureSkipVerify: true,
>> }
>>
>> transport := &http.Transport{
>> DisableKeepAlives: true,
>> TLSClientCOnfig: tlsCOnfig,
>> ResponseHeaderTimeout: time.Duration(headerTimeout) * time.Second,
>> }
>>
>> client := &http.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/dd7c3fa9-2eb9-4612-9221-7b2e6a1186cfn%40googlegroups.com.

[go-nuts] Building the embedded static assets prototype

[David Moles]

I'm trying to build the prototype code 
 for the embedded static 
assets proposal 
, but 
I'm not having any luck. I'm new to building Go from source, and new to 
gerrit and to the Go contribution & development process, so apologies in 
advance if I'm missing something obvious.

I've cloned the Go source and applied the change with

git fetch https://go.googlesource.com/go refs/changes/45/243945/2 && git 
checkout -b change-243945 FETCH_HEAD

but when I try to build with src/all.bash (using either go 1.15.2 or go 
1.14.9, on macOS Catalina), I get:

/Users/david/Projects/Scratch/goroot/src/cmd/internal/obj/dwarf.go:49: 
s.Func.Text undefined (type func() *FuncInfo has no field or method Text)

followed by a bunch of similar errors. (Note that neither dwarf.go nor 
funcinfo.go are involved in the prototype patchset.)

Figuring the tree might have been in a broken state at the time the 
prototype was committed, I then tried cherry-picking the commit (95a456f) 
on top of the go1.15.2 release tag. This got me past the error above, but 
the build then failed with:

go tool dist: FAILED: 
/Users/david/Projects/Scratch/goroot/pkg/tool/darwin_amd64/compile -std 
-pack -o 
/var/folders/mq/dw4wtwsn7dlb_q99_qcd9kdcgn/T/go-tool-dist-150877791/cmd/go/internal/load/_go_.a
 
-p cmd/go/internal/load -importcfg 
/var/folders/mq/dw4wtwsn7dlb_q99_qcd9kdcgn/T/go-tool-dist-150877791/cmd/go/internal/load/importcfg
 
/Users/david/Projects/Scratch/goroot/src/cmd/go/internal/load/flag.go 
/Users/david/Projects/Scratch/goroot/src/cmd/go/internal/load/path.go 
/Users/david/Projects/Scratch/goroot/src/cmd/go/internal/load/pkg.go 
/Users/david/Projects/Scratch/goroot/src/cmd/go/internal/load/search.go 
/Users/david/Projects/Scratch/goroot/src/cmd/go/internal/load/test.go: exit 
status 2
go tool dist: open 
/var/folders/mq/dw4wtwsn7dlb_q99_qcd9kdcgn/T/go-tool-dist-150877791/cmd/go/internal/modfetch/codehost/_go_.a:
 
no such file or directory
go tool dist: open 
/var/folders/mq/dw4wtwsn7dlb_q99_qcd9kdcgn/T/go-tool-dist-150877791/cmd/go/internal/load/_go_.a:
 
no such file or directory
go tool dist: open 
/var/folders/mq/dw4wtwsn7dlb_q99_qcd9kdcgn/T/go-tool-dist-150877791/cmd/go/internal/version/_go_.a:
 
no such file or directory

I assume that I'm doing this wrong, and that there's a right way to be 
doing it -- what is the right way? 

-- 
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/8633b006-6b07-4f5d-9dbf-baf28d492393n%40googlegroups.com.

Re: [go-nuts] Building the embedded static assets prototype

[Ian Lance Taylor]

On Thu, Oct 8, 2020 at 3:46 PM David Moles  wrote:
>
> I'm trying to build the prototype code for the embedded static assets 
> proposal, but I'm not having any luck. I'm new to building Go from source, 
> and new to gerrit and to the Go contribution & development process, so 
> apologies in advance if I'm missing something obvious.
>
> I've cloned the Go source and applied the change with
>
> git fetch https://go.googlesource.com/go refs/changes/45/243945/2 && git 
> checkout -b change-243945 FETCH_HEAD
>
> but when I try to build with src/all.bash (using either go 1.15.2 or go 
> 1.14.9, on macOS Catalina), I get:
>
> /Users/david/Projects/Scratch/goroot/src/cmd/internal/obj/dwarf.go:49: 
> s.Func.Text undefined (type func() *FuncInfo has no field or method Text)
>
> followed by a bunch of similar errors. (Note that neither dwarf.go nor 
> funcinfo.go are involved in the prototype patchset.)
>
> Figuring the tree might have been in a broken state at the time the prototype 
> was committed, I then tried cherry-picking the commit (95a456f) on top of the 
> go1.15.2 release tag. This got me past the error above, but the build then 
> failed with:
>
> go tool dist: FAILED: 
> /Users/david/Projects/Scratch/goroot/pkg/tool/darwin_amd64/compile -std -pack 
> -o 
> /var/folders/mq/dw4wtwsn7dlb_q99_qcd9kdcgn/T/go-tool-dist-150877791/cmd/go/internal/load/_go_.a
>  -p cmd/go/internal/load -importcfg 
> /var/folders/mq/dw4wtwsn7dlb_q99_qcd9kdcgn/T/go-tool-dist-150877791/cmd/go/internal/load/importcfg
>  /Users/david/Projects/Scratch/goroot/src/cmd/go/internal/load/flag.go 
> /Users/david/Projects/Scratch/goroot/src/cmd/go/internal/load/path.go 
> /Users/david/Projects/Scratch/goroot/src/cmd/go/internal/load/pkg.go 
> /Users/david/Projects/Scratch/goroot/src/cmd/go/internal/load/search.go 
> /Users/david/Projects/Scratch/goroot/src/cmd/go/internal/load/test.go: exit 
> status 2
> go tool dist: open 
> /var/folders/mq/dw4wtwsn7dlb_q99_qcd9kdcgn/T/go-tool-dist-150877791/cmd/go/internal/modfetch/codehost/_go_.a:
>  no such file or directory
> go tool dist: open 
> /var/folders/mq/dw4wtwsn7dlb_q99_qcd9kdcgn/T/go-tool-dist-150877791/cmd/go/internal/load/_go_.a:
>  no such file or directory
> go tool dist: open 
> /var/folders/mq/dw4wtwsn7dlb_q99_qcd9kdcgn/T/go-tool-dist-150877791/cmd/go/internal/version/_go_.a:
>  no such file or directory
>
> I assume that I'm doing this wrong, and that there's a right way to be doing 
> it -- what is the right way?


These errors look like you have some mix of old and new sources.  Make
sure to start with an empty directory, with no files left over from
earlier changes.

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/CAOyqgcXp4H7sxAX437jkZ%3DdfB%3D_aQ%2BwvOSPhEbp_5QT-hMa3hw%40mail.gmail.com.

Re: [go-nuts] Re: Will there be something like "net/quic" in the future?

[ran...@gmail.com]

On Friday, October 9, 2020 at 1:16:58 AM UTC+8 axel.wa... wrote:

> OP wrote "as you may have already heard, the standardization for QUIC is 
> almost done", implying this was a question about a future, stable spec for 
> QUIC. 
>

Exactly. I was wondering whether or not Go will ship a QUIC package in the 
future when the standardization process is completed by people at IETF.

6 month release cycle is fine for a stabilized protocol, right?

-- 
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/0f3acd5b-38d9-47d7-b021-be34db92e839n%40googlegroups.com.

[go-nuts] Positional arguments and flag package

[Amit Saha]

Hi all, I realize that the flag package stops parsing os.Args[] once it 
finds a non "-" character. This means, if I invoke my program as:

$ ./myprog arg1 -d value

flag.Parse() will stop parsing the moment it sees arg1 and result in NArg() 
returning 2 instead of 1. 

Is there a recommended workaround to handle both $./myprog -d value arg1 
and $./myprog arg1 -d value correctly? 

Thanks for any suggestions.

Thanks,
Amit.

-- 
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/d1399079-4589-454f-91d3-820a60aa239dn%40googlegroups.com.