Re: [go-nuts] YAEHI (Yet another error-handling idea)

[Andrey Tcherepanov]

Thanks Liam,

your suggested placement would make it somehow impossible (or at least I 
cannot see it right now) to use with someExpression?.someMember
If I am not mistaken, yours is close to the currently proposed "try", just 
replacing it with ?, am I right on that ?

A.

On Monday, July 1, 2019 at 2:49:09 AM UTC-6, Liam wrote:
>
> I've noted in several places that a 'try' expression (via keyword, 
> built-in, or symbol) is suitable only when the function is expected to 
> always succeed, and so would panic on error.
>
> Also the symbol, which I agree is preferable, works best this way 
> will?(always?(work?())) vs will(always(work()?)?)?
>
> On Saturday, June 29, 2019 at 4:05:44 PM UTC-7, Michael Jones wrote:
>>
>> My personal thought, though it may seem strange, is that the best 
>> argument for it lies in the single word sentence at the bottom of your 
>> email. You write "Thoughts?" -- and that is very expressive in English in 
>> just the way that you mean above in your examples. I don't know enough 
>> other languages to really know if the parallels are universal, but it's 
>> pretty clear to me what it means why "file?.close()" and 
>> "os.Open(filename)?" are "punctuated" as they are -- where the question is. 
>> I feel like you're asking this compiler, "is there anything about this 
>> value that you need to tell me?" I like that.
>>
>> The long (crazy long!) discussion of error handling has among its many 
>> branches an analysis from the Go team about '?' and this kind of postfix 
>> interrogation. I'm watching it all with a bit of wonder, but I wanted to 
>> speak up and say how your human-language phrasing matches your idea of 
>> computer-language phrasing. That seems a powerful kind of naturalness to 
>> take advantage of in this issue and future ones.
>>
>> On Sat, Jun 29, 2019 at 2:56 PM Andrey Tcherepanov <
>> xnow4f...@sneakemail.com> wrote:
>>
>>> Hello mighty fighters of errors!
>>>
>>> Here comes my half-thought idea of another way to express error handling:
>>>
>>> *Add a postfix '?' that checks value for **emptiness (nil, 0, "") **AND 
>>> an error for nil. *
>>>
>>> (Denis have shred it to pieces already in 
>>> https://github.com/golang/go/issues/32852. Thank you Denis.)
>>>
>>> I am not good with expressing my inner talk, so there are couple examples
>>>
>>> original , Go 1 function
>>>
>>> func stat(filename string) (os.FileInfo, error) {
>>>
>>> var info os.FileInfo
>>> {
>>> var a1 *os.File
>>> if a1, err := os.Open(filename); err != nil || a1 == nil {
>>> return _, err
>>> }
>>> var a2 os.FileInfo
>>> if a2, err := a1.Stat(); err != nil || a2 == nil {
>>> return _, err
>>> }
>>> info = a2
>>> }
>>> return info, nil
>>> }
>>>
>>>
>>> And with "?", trying to avoid original try() proposal handle leak
>>>
>>> // would return _, err, but since there is no err in signature, will return 
>>> default value in case of error
>>> // uses ? on func call that returns (value, error)
>>> func stat2(filename string) (os.FileInfo) {
>>>  file := os.Open(filename)? 
>>>  defer file.Close()
>>>  return file.Stat()?
>>> }
>>> // would return error too, uses ? as "not nil" on a variable too
>>> func stat3(filename string) (_ os.FileInfo, err error) {
>>>  var file *os.File
>>>  defer file?.Close()
>>>  file := os.Open(filename)?
>>>  return file.Stat()
>>> }
>>>
>>>
>>> Thoughts?
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to golan...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/b7520ffe-ec38-4157-8f95-92844dcb0d0f%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> -- 
>>
>> *Michael T. jonesmichae...@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/93987580-3f1d-4ab8-b796-2e095d49a3b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] OOM occurring with a small heap

[robert engels]

One other thing to think about - 500 qps is a lot for a single server if things 
start blocking and you have a low memory cap. Imagine the scenario where the 
DynamoDB “locks up / heavy delays due to IO contention / something”, depending 
on how your server is written/configured it may still keep accepting inbound 
connections, each potentially causing a thread to be created (if they are doing 
blocking IO). If there is not a low cap on the number of inbound connections 
you could quickly run out of memory. You might want to see if there is a 
configuration option on grpc-gateway to limit the maximum number of 
simultaneous inbound connections, set that to a low number, and see if it still 
runs out of memory.

This scenario is unlikely if you didn’t see the TCPConn instances in the heap 
dump.

> On Jul 1, 2019, at 11:28 PM, Mighty Guava  wrote:
> 
> Oh now that you mention it, I'm using grpc-gateway with the stdlib http 
> server. Though all it really does is convert json <=> protobuf and is pretty 
> mature so it's unlikely to be the culprit.
> 
> Running with race detector is a good idea! I'll try that tomorrow.
> 
> Thanks,
> Yunchi Luo
> On Jul 2, 2019, 12:25 AM -0400, robert engels , wrote:
>> Are you using anything like fast-http, or such? Have you tried running the 
>> server with the race-detector enabled? I could see a race condition causing 
>> a rare failure that causes the code to go into a ‘spinning loop’ preventing 
>> GC to work properly. It’s a guess but I would try that to rule out the 
>> possibility.
>> 
>>> On Jul 1, 2019, at 11:06 PM, Mighty Guava >> > wrote:
>>> 
>>> I don't think GC is being blocked. GC ran multiple times during the time 
>>> the service was exploding in memory. 
>>> 
>>> I'm not using mmap in the service. It's just a straightforward CRUD 
>>> webserver backed by DynamoDB. The only thing non-standard I can think of is 
>>> that it connects to its backing database over HTTP/1.1 (using AWS Go SDK) 
>>> instead of a custom database protocol. It's serving a fair amount of 
>>> requests (500 qps per replica), so I initially assumed it was 
>>> under-provisioned to handle latency spikes. But I tripled the memory and 
>>> it's still OOMing on occasion, even though RSS is 9% of allocated memory 
>>> just seconds before. 
>>> 
>>> Yunchi
>>> On Jul 2, 2019, 12:00 AM -0400, Robert Engels >> >, wrote:
 Does your process use mmap? Maybe you are leaking there, as this counts 
 against process memory size. 
 
 On Jul 1, 2019, at 9:11 PM, Mighty Guava >>> > wrote:
 
> I don't understand. What would adding runtime.Goscheduled() do here? I 
> don't have any explicit loops in this service.
> On Jul 1, 2019, 9:11 PM -0400, Michael Jones  >, wrote:
>> Does adding runtime.GoSched() calls make any difference?
>> 
>> On Mon, Jul 1, 2019 at 5:37 PM 'Yunchi Luo' via golang-nuts 
>> mailto:golang-nuts@googlegroups.com>> 
>> wrote:
>> Following that logic, a leak of TCP connections should manifest as a 
>> file descriptor leak. We have the process_open_fds metric from 
>> Prometheus, that is the number of open file descriptors as found in 
>> /proc//fd. The number of descriptors overtime correlates well with 
>> the amount of traffic, pretty cyclic. There doesn't appear to be a leak.
>> 
>> We don't do our own memory management and the binary is compiled with 
>> CGO_ENABLED=0.
>> 
>> I still think the issue I'm seeing should be GC (or heap) related, given 
>> the explosion in mark & sweep time, HeapSys, HeapIdle, and HeapReleased 
>> just before the process dies. But I'm lacking ideas on how to track down 
>> the cause of the increase.
>> 
>> On Mon, Jul 1, 2019 at 5:39 PM Robert Engels > > wrote:
>> I think don't think you are going to find it in the 'heap', rather it 
>> would be in native memory.
>> 
>> I would use the monitor the /proc/[pid] for the process, and pay 
>> attention to the 'fd','net' and 'statm' - if my theory is correct you 
>> will see growth here long before the process is killed. Since you are 
>> running under k8s and cgroups, you will need to do this along side the 
>> Go process (unless you have root access to the server).
>> 
>> I 'think' depending on kernel version, that kernel memory used goes 
>> against the process for OOM purposes, so this is a likely candidate if 
>> pprof is showing nothing.
>> 
>> Do you by chance do any of your own memory management (via malloc/CGO)? 
>> If so, this is not going to show in pprof either.
>> -Original Message-
>> From: 'Yunchi Luo' via golang-nuts 
>> Sent: Jul 1, 2019 4:26 PM
>> To: Robert Engels 
>> Cc: golang-nuts@googlegroups.com 

Re: [go-nuts] OOM occurring with a small heap

[robert engels]

Are you using anything like fast-http, or such? Have you tried running the 
server with the race-detector enabled? I could see a race condition causing a 
rare failure that causes the code to go into a ‘spinning loop’ preventing GC to 
work properly. It’s a guess but I would try that to rule out the possibility.

> On Jul 1, 2019, at 11:06 PM, Mighty Guava  wrote:
> 
> I don't think GC is being blocked. GC ran multiple times during the time the 
> service was exploding in memory. 
> 
> I'm not using mmap in the service. It's just a straightforward CRUD webserver 
> backed by DynamoDB. The only thing non-standard I can think of is that it 
> connects to its backing database over HTTP/1.1 (using AWS Go SDK) instead of 
> a custom database protocol. It's serving a fair amount of requests (500 qps 
> per replica), so I initially assumed it was under-provisioned to handle 
> latency spikes. But I tripled the memory and it's still OOMing on occasion, 
> even though RSS is 9% of allocated memory just seconds before. 
> 
> Yunchi
> On Jul 2, 2019, 12:00 AM -0400, Robert Engels , wrote:
>> Does your process use mmap? Maybe you are leaking there, as this counts 
>> against process memory size. 
>> 
>> On Jul 1, 2019, at 9:11 PM, Mighty Guava > > wrote:
>> 
>>> I don't understand. What would adding runtime.Goscheduled() do here? I 
>>> don't have any explicit loops in this service.
>>> On Jul 1, 2019, 9:11 PM -0400, Michael Jones >> >, wrote:
 Does adding runtime.GoSched() calls make any difference?
 
 On Mon, Jul 1, 2019 at 5:37 PM 'Yunchi Luo' via golang-nuts 
 mailto:golang-nuts@googlegroups.com>> wrote:
 Following that logic, a leak of TCP connections should manifest as a file 
 descriptor leak. We have the process_open_fds metric from Prometheus, that 
 is the number of open file descriptors as found in /proc//fd. The 
 number of descriptors overtime correlates well with the amount of traffic, 
 pretty cyclic. There doesn't appear to be a leak.
 
 We don't do our own memory management and the binary is compiled with 
 CGO_ENABLED=0.
 
 I still think the issue I'm seeing should be GC (or heap) related, given 
 the explosion in mark & sweep time, HeapSys, HeapIdle, and HeapReleased 
 just before the process dies. But I'm lacking ideas on how to track down 
 the cause of the increase.
 
 On Mon, Jul 1, 2019 at 5:39 PM Robert Engels >>> > wrote:
 I think don't think you are going to find it in the 'heap', rather it 
 would be in native memory.
 
 I would use the monitor the /proc/[pid] for the process, and pay attention 
 to the 'fd','net' and 'statm' - if my theory is correct you will see 
 growth here long before the process is killed. Since you are running under 
 k8s and cgroups, you will need to do this along side the Go process 
 (unless you have root access to the server).
 
 I 'think' depending on kernel version, that kernel memory used goes 
 against the process for OOM purposes, so this is a likely candidate if 
 pprof is showing nothing.
 
 Do you by chance do any of your own memory management (via malloc/CGO)? If 
 so, this is not going to show in pprof either.
 -Original Message-
 From: 'Yunchi Luo' via golang-nuts 
 Sent: Jul 1, 2019 4:26 PM
 To: Robert Engels 
 Cc: golang-nuts@googlegroups.com , 
 Alec Thomas 
 Subject: Re: [go-nuts] OOM occurring with a small heap
 
 I actually have a heap profile (pasted at the bottom) from about 1 second 
 before the service died (the goroutine that is logging "[Memory]" triggers 
 heap profiles once RSS > 100MB). I don't see TCP connections there. Maybe 
 it's too few to be sampled. How would I verify your theory? That the 
 service dies within 2 seconds after several hours makes it very hard to 
 debug.
 
 The top thing in the heap profile is from the reflect package. I initially 
 found that suspect, but it turns out this comes from a use of 
 httptrace.ClientTrace I had for counting new connections to DynamoDB.
 
  tracer := {
ConnectStart: func(_, _ string) {
  newConns.Inc()
},
 }
 
 `newConns` is just a prometheus counter. The `tracer` object itself is 
 created once and re-used with every client request context. On request, 
 `httptrace.WithClientTrace(ctx, tracer)` uses reflection to compose the 
 trace functions under-the-hood and uses reflection to invoke it, hence the 
 reflect.funcLayout and reflect.Value.call. Objects in `reflect` account 
 for about 50% of heap in terms of size, and does seem to grow as the 
 service is running out of memory, but that's only 12MB so I thought it was 
 a red herring.
 
 Heap profile:
 Type: 

Re: [go-nuts] OOM occurring with a small heap

[Robert Engels]

Does your process use mmap? Maybe you are leaking there, as this counts against 
process memory size. 

> On Jul 1, 2019, at 9:11 PM, Mighty Guava  wrote:
> 
> I don't understand. What would adding runtime.Goscheduled() do here? I don't 
> have any explicit loops in this service.
>> On Jul 1, 2019, 9:11 PM -0400, Michael Jones , 
>> wrote:
>> Does adding runtime.GoSched() calls make any difference?
>> 
>> On Mon, Jul 1, 2019 at 5:37 PM 'Yunchi Luo' via golang-nuts 
>>  wrote:
>> Following that logic, a leak of TCP connections should manifest as a file 
>> descriptor leak. We have the process_open_fds metric from Prometheus, that 
>> is the number of open file descriptors as found in /proc//fd. The 
>> number of descriptors overtime correlates well with the amount of traffic, 
>> pretty cyclic. There doesn't appear to be a leak.
>> 
>> We don't do our own memory management and the binary is compiled with 
>> CGO_ENABLED=0.
>> 
>> I still think the issue I'm seeing should be GC (or heap) related, given the 
>> explosion in mark & sweep time, HeapSys, HeapIdle, and HeapReleased just 
>> before the process dies. But I'm lacking ideas on how to track down the 
>> cause of the increase.
>> 
>> On Mon, Jul 1, 2019 at 5:39 PM Robert Engels  wrote:
>> I think don't think you are going to find it in the 'heap', rather it would 
>> be in native memory.
>> 
>> I would use the monitor the /proc/[pid] for the process, and pay attention 
>> to the 'fd','net' and 'statm' - if my theory is correct you will see growth 
>> here long before the process is killed. Since you are running under k8s and 
>> cgroups, you will need to do this along side the Go process (unless you have 
>> root access to the server).
>> 
>> I 'think' depending on kernel version, that kernel memory used goes against 
>> the process for OOM purposes, so this is a likely candidate if pprof is 
>> showing nothing.
>> 
>> Do you by chance do any of your own memory management (via malloc/CGO)? If 
>> so, this is not going to show in pprof either.
>> -Original Message-
>> From: 'Yunchi Luo' via golang-nuts 
>> Sent: Jul 1, 2019 4:26 PM
>> To: Robert Engels 
>> Cc: golang-nuts@googlegroups.com, Alec Thomas 
>> Subject: Re: [go-nuts] OOM occurring with a small heap
>> 
>> I actually have a heap profile (pasted at the bottom) from about 1 second 
>> before the service died (the goroutine that is logging "[Memory]" triggers 
>> heap profiles once RSS > 100MB). I don't see TCP connections there. Maybe 
>> it's too few to be sampled. How would I verify your theory? That the service 
>> dies within 2 seconds after several hours makes it very hard to debug.
>> 
>> The top thing in the heap profile is from the reflect package. I initially 
>> found that suspect, but it turns out this comes from a use of 
>> httptrace.ClientTrace I had for counting new connections to DynamoDB.
>> 
>>  tracer := {
>>ConnectStart: func(_, _ string) {
>>  newConns.Inc()
>>},
>> }
>> 
>> `newConns` is just a prometheus counter. The `tracer` object itself is 
>> created once and re-used with every client request context. On request, 
>> `httptrace.WithClientTrace(ctx, tracer)` uses reflection to compose the 
>> trace functions under-the-hood and uses reflection to invoke it, hence the 
>> reflect.funcLayout and reflect.Value.call. Objects in `reflect` account for 
>> about 50% of heap in terms of size, and does seem to grow as the service is 
>> running out of memory, but that's only 12MB so I thought it was a red 
>> herring.
>> 
>> Heap profile:
>> Type: inuse_space
>> Time: Jun 30, 2019 at 4:46am (EDT)
>> Entering interactive mode (type "help" for commands, "o" for options)
>> (pprof) inuse_objects
>> (pprof) top
>> Showing nodes accounting for 414485, 100% of 414485 total
>> Showing top 10 nodes out of 81
>>   flat  flat%   sum%cum   cum%
>> 344074 83.01% 83.01% 344074 83.01%  reflect.funcLayout.func1
>>  32768  7.91% 90.92% 376842 90.92%  reflect.callReflect
>>  16384  3.95% 94.87%  16384  3.95%  
>> github.com/json-iterator/go.processTags
>>  10923  2.64% 97.51%  10923  2.64%  context.WithValue
>>   8192  1.98% 99.48%   8192  1.98%  crypto/hmac.New
>>   1260   0.3% 99.79%   1260   0.3%  
>> github.com/aws/aws-sdk-go/aws/signer/v4.(*signingCtx).buildCanonicalHeaders
>>820   0.2%   100%820   0.2%  
>> github.com/stripe/veneur/tdigest.NewMerging
>> 64 0.015%   100% 64 0.015%  reflect.addReflectOff
>>  0 0%   100%820   0.2%  
>> git.sqcorp.co/cash/digester/lib/pkg/histogram.(*SlidingWindowDigest).Observe
>>  0 0%   100%820   0.2%  
>> git.sqcorp.co/cash/digester/lib/pkg/histogram.(*SlidingWindowDigest).openDigests
>> (pprof) cum
>> (pprof) top
>> Showing nodes accounting for 376842, 90.92% of 414485 total
>> Showing top 10 nodes out of 81
>>   flat  flat%   sum%cum   cum%
>>  0 0% 0% 376842 90.92%  
>> 

Re: [go-nuts] OOM occurring with a small heap

[Michael Jones]

One theory you advanced is of a desperate garbage collector. If you prevent
it from running all along, then maybe that could be possible. Pursuing that
line of reasoning I though you could ensure it’s chances with gosched() in
your code.

On Mon, Jul 1, 2019 at 7:17 PM Mighty Guava  wrote:

> I don't understand. What would adding runtime.Goscheduled() do here? I
> don't have any explicit loops in this service.
> On Jul 1, 2019, 9:11 PM -0400, Michael Jones ,
> wrote:
>
> Does adding runtime.GoSched() calls make any difference?
>
> On Mon, Jul 1, 2019 at 5:37 PM 'Yunchi Luo' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> Following that logic, a leak of TCP connections should manifest as a file
> descriptor leak. We have the process_open_fds metric from Prometheus, that
> is the number of open file descriptors as found in /proc//fd. The
> number of descriptors overtime correlates well with the amount of traffic,
> pretty cyclic. There doesn't appear to be a leak.
>
> We don't do our own memory management and the binary is compiled with
> CGO_ENABLED=0.
>
> I still think the issue I'm seeing should be GC (or heap) related, given
> the explosion in mark & sweep time, HeapSys, HeapIdle, and HeapReleased
> just before the process dies. But I'm lacking ideas on how to track down
> the cause of the increase.
>
> On Mon, Jul 1, 2019 at 5:39 PM Robert Engels 
> wrote:
>
> I think don't think you are going to find it in the 'heap', rather it
> would be in native memory.
>
> I would use the monitor the /proc/[pid] for the process, and pay attention
> to the 'fd','net' and 'statm' - if my theory is correct you will see growth
> here long before the process is killed. Since you are running under k8s and
> cgroups, you will need to do this along side the Go process (unless you
> have root access to the server).
>
> I 'think' depending on kernel version, that kernel memory used goes
> against the process for OOM purposes, so this is a likely candidate if
> pprof is showing nothing.
>
> Do you by chance do any of your own memory management (via malloc/CGO)? If
> so, this is not going to show in pprof either.
>
> -Original Message-
> From: 'Yunchi Luo' via golang-nuts
> Sent: Jul 1, 2019 4:26 PM
> To: Robert Engels
> Cc: golang-nuts@googlegroups.com, Alec Thomas
> Subject: Re: [go-nuts] OOM occurring with a small heap
>
> I actually have a heap profile (pasted at the bottom) from about 1 second
> before the service died (the goroutine that is logging "[Memory]" triggers
> heap profiles once RSS > 100MB). I don't see TCP connections there. Maybe
> it's too few to be sampled. How would I verify your theory? That the
> service dies within 2 seconds after several hours makes it very hard to
> debug.
>
> The top thing in the heap profile is from the reflect package. I initially
> found that suspect, but it turns out this comes from a use of
> httptrace.ClientTrace I had for counting new connections to DynamoDB.
>
>  tracer := {
>ConnectStart: func(_, _ string) {
>  newConns.Inc()
>},
> }
>
> `newConns` is just a prometheus counter. The `tracer` object itself is
> created once and re-used with every client request context. On request,
> `httptrace.WithClientTrace(ctx, tracer)` uses reflection to compose the
> trace functions under-the-hood and uses reflection to invoke it, hence the
> reflect.funcLayout and reflect.Value.call. Objects in `reflect` account for
> about 50% of heap in terms of size, and does seem to grow as the service is
> running out of memory, but that's only 12MB so I thought it was a red
> herring.
>
> Heap profile:
> Type: inuse_space
> Time: Jun 30, 2019 at 4:46am (EDT)
> Entering interactive mode (type "help" for commands, "o" for options)
> (pprof) inuse_objects
> (pprof) top
> Showing nodes accounting for 414485, 100% of 414485 total
> Showing top 10 nodes out of 81
>   flat  flat%   sum%cum   cum%
> 344074 83.01% 83.01% 344074 83.01%  reflect.funcLayout.func1
>  32768  7.91% 90.92% 376842 90.92%  reflect.callReflect
>  16384  3.95% 94.87%  16384  3.95%
> github.com/json-iterator/go.processTags
>  10923  2.64% 97.51%  10923  2.64%  context.WithValue
>   8192  1.98% 99.48%   8192  1.98%  crypto/hmac.New
>   1260   0.3% 99.79%   1260   0.3%
> github.com/aws/aws-sdk-go/aws/signer/v4.(*signingCtx).buildCanonicalHeaders
>820   0.2%   100%820   0.2%
> github.com/stripe/veneur/tdigest.NewMerging
> 64 0.015%   100% 64 0.015%  reflect.addReflectOff
>  0 0%   100%820   0.2%
> git.sqcorp.co/cash/digester/lib/pkg/histogram.(*SlidingWindowDigest).Observe
>  0 0%   100%820   0.2%
> git.sqcorp.co/cash/digester/lib/pkg/histogram.(*SlidingWindowDigest).openDigests
> (pprof) cum
> (pprof) top
> Showing nodes accounting for 376842, 90.92% of 414485 total
> Showing top 10 nodes out of 81
>   flat  flat%   sum%cum   cum%
>  0 0% 0% 

Re: [go-nuts] Reflection: How to retrieve index of map

[Dan Kortschak]

You can use the Index method on reflect.Value if it is an integer-
indexable type.

https://play.golang.org/p/07YXRPBMqo6

On Mon, 2019-07-01 at 12:45 -0700, Mark Bauermeister wrote:
> I have the following code, where the TokenMap struct is actually part
> of another package. 
> idMap is not exported and thus not accessible without reflection.
> 
> Through reflection I can easily find the value of "int", which is
> "28".
> Now, I'd like to do the opposite though. I'd like to find "28"'s
> index (i e "int").
> 
> How would I go about that?
> 
> https://play.golang.org/p/UnMi4gQGrIr
> -- 
> 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/844522f8-145c-44c1-b382-338c2936d5fb%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] OOM occurring with a small heap

[Michael Jones]

Does adding runtime.GoSched() calls make any difference?

On Mon, Jul 1, 2019 at 5:37 PM 'Yunchi Luo' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Following that logic, a leak of TCP connections should manifest as a file
> descriptor leak. We have the process_open_fds metric from Prometheus, that
> is the number of open file descriptors as found in /proc//fd. The
> number of descriptors overtime correlates well with the amount of traffic,
> pretty cyclic. There doesn't appear to be a leak.
>
> We don't do our own memory management and the binary is compiled with
> CGO_ENABLED=0.
>
> I still think the issue I'm seeing should be GC (or heap) related, given
> the explosion in mark & sweep time, HeapSys, HeapIdle, and HeapReleased
> just before the process dies. But I'm lacking ideas on how to track down
> the cause of the increase.
>
> On Mon, Jul 1, 2019 at 5:39 PM Robert Engels 
> wrote:
>
>> I think don't think you are going to find it in the 'heap', rather it
>> would be in native memory.
>>
>> I would use the monitor the /proc/[pid] for the process, and pay
>> attention to the 'fd','net' and 'statm' - if my theory is correct you will
>> see growth here long before the process is killed. Since you are running
>> under k8s and cgroups, you will need to do this along side the Go process
>> (unless you have root access to the server).
>>
>> I 'think' depending on kernel version, that kernel memory used goes
>> against the process for OOM purposes, so this is a likely candidate if
>> pprof is showing nothing.
>>
>> Do you by chance do any of your own memory management (via malloc/CGO)?
>> If so, this is not going to show in pprof either.
>>
>> -Original Message-
>> From: 'Yunchi Luo' via golang-nuts
>> Sent: Jul 1, 2019 4:26 PM
>> To: Robert Engels
>> Cc: golang-nuts@googlegroups.com, Alec Thomas
>> Subject: Re: [go-nuts] OOM occurring with a small heap
>>
>> I actually have a heap profile (pasted at the bottom) from about 1 second
>> before the service died (the goroutine that is logging "[Memory]" triggers
>> heap profiles once RSS > 100MB). I don't see TCP connections there. Maybe
>> it's too few to be sampled. How would I verify your theory? That the
>> service dies within 2 seconds after several hours makes it very hard to
>> debug.
>>
>> The top thing in the heap profile is from the reflect package. I
>> initially found that suspect, but it turns out this comes from a use of
>> httptrace.ClientTrace I had for counting new connections to DynamoDB.
>>
>>  tracer := {
>>ConnectStart: func(_, _ string) {
>>  newConns.Inc()
>>},
>> }
>>
>> `newConns` is just a prometheus counter. The `tracer` object itself is
>> created once and re-used with every client request context. On request,
>> `httptrace.WithClientTrace(ctx, tracer)` uses reflection to compose the
>> trace functions under-the-hood and uses reflection to invoke it, hence the
>> reflect.funcLayout and reflect.Value.call. Objects in `reflect` account for
>> about 50% of heap in terms of size, and does seem to grow as the service is
>> running out of memory, but that's only 12MB so I thought it was a red
>> herring.
>>
>> Heap profile:
>> Type: inuse_space
>> Time: Jun 30, 2019 at 4:46am (EDT)
>> Entering interactive mode (type "help" for commands, "o" for options)
>> (pprof) inuse_objects
>> (pprof) top
>> Showing nodes accounting for 414485, 100% of 414485 total
>> Showing top 10 nodes out of 81
>>   flat  flat%   sum%cum   cum%
>> 344074 83.01% 83.01% 344074 83.01%  reflect.funcLayout.func1
>>  32768  7.91% 90.92% 376842 90.92%  reflect.callReflect
>>  16384  3.95% 94.87%  16384  3.95%
>> github.com/json-iterator/go.processTags
>>  10923  2.64% 97.51%  10923  2.64%  context.WithValue
>>   8192  1.98% 99.48%   8192  1.98%  crypto/hmac.New
>>   1260   0.3% 99.79%   1260   0.3%
>> github.com/aws/aws-sdk-go/aws/signer/v4.(*signingCtx).buildCanonicalHeaders
>>820   0.2%   100%820   0.2%
>> github.com/stripe/veneur/tdigest.NewMerging
>> 64 0.015%   100% 64 0.015%  reflect.addReflectOff
>>  0 0%   100%820   0.2%
>> git.sqcorp.co/cash/digester/lib/pkg/histogram.(*SlidingWindowDigest).Observe
>>  0 0%   100%820   0.2%
>> git.sqcorp.co/cash/digester/lib/pkg/histogram.(*SlidingWindowDigest).openDigests
>> (pprof) cum
>> (pprof) top
>> Showing nodes accounting for 376842, 90.92% of 414485 total
>> Showing top 10 nodes out of 81
>>   flat  flat%   sum%cum   cum%
>>  0 0% 0% 376842 90.92%
>>  net/http/httptrace.(*ClientTrace).compose.func1
>>  0 0% 0% 376842 90.92%  reflect.Value.Call
>>  0 0% 0% 376842 90.92%  reflect.Value.call
>>  32768  7.91%  7.91% 376842 90.92%  reflect.callReflect
>>  0 0%  7.91% 376842 90.92%  reflect.makeFuncStub
>> 344074 83.01% 90.92% 344074 83.01%  

Re: [go-nuts] OOM occurring with a small heap

['Yunchi Luo' via golang-nuts]

Following that logic, a leak of TCP connections should manifest as a file
descriptor leak. We have the process_open_fds metric from Prometheus, that
is the number of open file descriptors as found in /proc//fd. The
number of descriptors overtime correlates well with the amount of traffic,
pretty cyclic. There doesn't appear to be a leak.

We don't do our own memory management and the binary is compiled with
CGO_ENABLED=0.

I still think the issue I'm seeing should be GC (or heap) related, given
the explosion in mark & sweep time, HeapSys, HeapIdle, and HeapReleased
just before the process dies. But I'm lacking ideas on how to track down
the cause of the increase.

On Mon, Jul 1, 2019 at 5:39 PM Robert Engels  wrote:

> I think don't think you are going to find it in the 'heap', rather it
> would be in native memory.
>
> I would use the monitor the /proc/[pid] for the process, and pay attention
> to the 'fd','net' and 'statm' - if my theory is correct you will see growth
> here long before the process is killed. Since you are running under k8s and
> cgroups, you will need to do this along side the Go process (unless you
> have root access to the server).
>
> I 'think' depending on kernel version, that kernel memory used goes
> against the process for OOM purposes, so this is a likely candidate if
> pprof is showing nothing.
>
> Do you by chance do any of your own memory management (via malloc/CGO)? If
> so, this is not going to show in pprof either.
>
> -Original Message-
> From: 'Yunchi Luo' via golang-nuts
> Sent: Jul 1, 2019 4:26 PM
> To: Robert Engels
> Cc: golang-nuts@googlegroups.com, Alec Thomas
> Subject: Re: [go-nuts] OOM occurring with a small heap
>
> I actually have a heap profile (pasted at the bottom) from about 1 second
> before the service died (the goroutine that is logging "[Memory]" triggers
> heap profiles once RSS > 100MB). I don't see TCP connections there. Maybe
> it's too few to be sampled. How would I verify your theory? That the
> service dies within 2 seconds after several hours makes it very hard to
> debug.
>
> The top thing in the heap profile is from the reflect package. I initially
> found that suspect, but it turns out this comes from a use of
> httptrace.ClientTrace I had for counting new connections to DynamoDB.
>
>  tracer := {
>ConnectStart: func(_, _ string) {
>  newConns.Inc()
>},
> }
>
> `newConns` is just a prometheus counter. The `tracer` object itself is
> created once and re-used with every client request context. On request,
> `httptrace.WithClientTrace(ctx, tracer)` uses reflection to compose the
> trace functions under-the-hood and uses reflection to invoke it, hence the
> reflect.funcLayout and reflect.Value.call. Objects in `reflect` account for
> about 50% of heap in terms of size, and does seem to grow as the service is
> running out of memory, but that's only 12MB so I thought it was a red
> herring.
>
> Heap profile:
> Type: inuse_space
> Time: Jun 30, 2019 at 4:46am (EDT)
> Entering interactive mode (type "help" for commands, "o" for options)
> (pprof) inuse_objects
> (pprof) top
> Showing nodes accounting for 414485, 100% of 414485 total
> Showing top 10 nodes out of 81
>   flat  flat%   sum%cum   cum%
> 344074 83.01% 83.01% 344074 83.01%  reflect.funcLayout.func1
>  32768  7.91% 90.92% 376842 90.92%  reflect.callReflect
>  16384  3.95% 94.87%  16384  3.95%
> github.com/json-iterator/go.processTags
>  10923  2.64% 97.51%  10923  2.64%  context.WithValue
>   8192  1.98% 99.48%   8192  1.98%  crypto/hmac.New
>   1260   0.3% 99.79%   1260   0.3%
> github.com/aws/aws-sdk-go/aws/signer/v4.(*signingCtx).buildCanonicalHeaders
>820   0.2%   100%820   0.2%
> github.com/stripe/veneur/tdigest.NewMerging
> 64 0.015%   100% 64 0.015%  reflect.addReflectOff
>  0 0%   100%820   0.2%
> git.sqcorp.co/cash/digester/lib/pkg/histogram.(*SlidingWindowDigest).Observe
>  0 0%   100%820   0.2%
> git.sqcorp.co/cash/digester/lib/pkg/histogram.(*SlidingWindowDigest).openDigests
> (pprof) cum
> (pprof) top
> Showing nodes accounting for 376842, 90.92% of 414485 total
> Showing top 10 nodes out of 81
>   flat  flat%   sum%cum   cum%
>  0 0% 0% 376842 90.92%
>  net/http/httptrace.(*ClientTrace).compose.func1
>  0 0% 0% 376842 90.92%  reflect.Value.Call
>  0 0% 0% 376842 90.92%  reflect.Value.call
>  32768  7.91%  7.91% 376842 90.92%  reflect.callReflect
>  0 0%  7.91% 376842 90.92%  reflect.makeFuncStub
> 344074 83.01% 90.92% 344074 83.01%  reflect.funcLayout.func1
>  0 0% 90.92% 344074 83.01%  sync.(*Pool).Get
>  0 0% 90.92%  16448  3.97%
> github.com/json-iterator/go._createDecoderOfType
>  0 0% 90.92%  16448  3.97%
> github.com/json-iterator/go.createDecoderOfType
>  0 

Re: [go-nuts] [ANN] gomvpkg: move a package, updating import declarations

[aoneal]

Correction:

cat go.mod

> module github.com/myuser/myproject


I had a correct go.mod in my project, I just updated it wrong when I posted 
the "sanitized" example. 

-- 
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/27f4ad81-ddae-4a71-a73b-29d052161bd2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] [ANN] gomvpkg: move a package, updating import declarations

[aoneal]

Does this tool no longer work since the move to go modules?

pushd myproject/

cat go.mod

> github.com/myuser/myproject

 
gomvpkg -from github.com/myuser/myproject/foo/bar -to 
github.com/myuser/myproject/foo/baz

> gomvpkg: src dir not found for package: 
> github.com/myuser/myproject/foo/bar.

-- 
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/1fff3fe1-486a-479f-9967-1858dc3fa099%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] goforward: What is it? How do I use it?

[aoneal]

>
>
> I'm not confident that there is now more documentation in this thread in 
> regards to go forward than there is anywhere else on the web.
>

I meant to say "I'm now confident that there is more ..."

What it does:

It reads an entire source package and outputs a single type alias file that 
describes the package.

The idea being that you may have few major breaking changes that need a new 
function definition or a new type, but the majority of code could stay the 
same between your v1 and v2, and it may be possible to fix many bugs or add 
many features to both v1 and v2 simultaneously this way.

How to use it:

  pushd ~/Code/github.com/example/go-foo

  cat go.mod

> module github.com/example/go-foo


  goforward github.com/example/go-foo/barpkg 
github.com/example/go-foo/barpkg/v2

What the result looks like:

  ls barpkg/v2/

> forward.go

 
  cat forward.go

> // generated by goforward github.com/example/go-foo/barpkg 
> github.com/example/go-foo/barpkg/v2
> package adapter
> import (
> "time"
> "github.com/example/go-foo/barpkg"
> ) 

 

// Sprockets by spacely are the best
> var Sprocket = barpkg.Sprocket 

 

// Widget does some such or other
> type Widget = barpkg.Widget  


> // New returns a Widget that's guaranteed to break by exp 

func New(exp time.Time) *Widget {
> return (exp)
> } 

-- 
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/b20f22e1-3385-4a7c-8e74-5b0019c123c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] OOM occurring with a small heap

[Robert Engels]

I think don't think you are going to find it in the 'heap', rather it would be in native memory.I would use the monitor the /proc/[pid] for the process, and pay attention to the 'fd','net' and 'statm' - if my theory is correct you will see growth here long before the process is killed. Since you are running under k8s and cgroups, you will need to do this along side the Go process (unless you have root access to the server).I 'think' depending on kernel version, that kernel memory used goes against the process for OOM purposes, so this is a likely candidate if pprof is showing nothing.Do you by chance do any of your own memory management (via malloc/CGO)? If so, this is not going to show in pprof either.-Original Message-
From: 'Yunchi Luo' via golang-nuts 
Sent: Jul 1, 2019 4:26 PM
To: Robert Engels 
Cc: golang-nuts@googlegroups.com, Alec Thomas 
Subject: Re: [go-nuts] OOM occurring with a small heap

I actually have a heap profile (pasted at the bottom) from about 1 second before the service died (the goroutine that is logging "[Memory]" triggers heap profiles once RSS > 100MB). I don't see TCP connections there. Maybe it's too few to be sampled. How would I verify your theory? That the service dies within 2 seconds after several hours makes it very hard to debug.The top thing in the heap profile is from the reflect package. I initially found that suspect, but it turns out this comes from a use of httptrace.ClientTrace I had for counting new connections to DynamoDB. tracer := {   ConnectStart: func(_, _ string) {     newConns.Inc()   },}`newConns` is just a prometheus counter. The `tracer` object itself is created once and re-used with every client request context. On request, `httptrace.WithClientTrace(ctx, tracer)` uses reflection to compose the trace functions under-the-hood and uses reflection to invoke it, hence the reflect.funcLayout and reflect.Value.call. Objects in `reflect` account for about 50% of heap in terms of size, and does seem to grow as the service is running out of memory, but that's only 12MB so I thought it was a red herring.Heap profile:Type: inuse_spaceTime: Jun 30, 2019 at 4:46am (EDT)Entering interactive mode (type "help" for commands, "o" for options)(pprof) inuse_objects(pprof) topShowing nodes accounting for 414485, 100% of 414485 totalShowing top 10 nodes out of 81      flat  flat%   sum%        cum   cum%    344074 83.01% 83.01%     344074 83.01%  reflect.funcLayout.func1     32768  7.91% 90.92%     376842 90.92%  reflect.callReflect     16384  3.95% 94.87%      16384  3.95%  github.com/json-iterator/go.processTags     10923  2.64% 97.51%      10923  2.64%  context.WithValue      8192  1.98% 99.48%       8192  1.98%  crypto/hmac.New      1260   0.3% 99.79%       1260   0.3%  github.com/aws/aws-sdk-go/aws/signer/v4.(*signingCtx).buildCanonicalHeaders       820   0.2%   100%        820   0.2%  github.com/stripe/veneur/tdigest.NewMerging        64 0.015%   100%         64 0.015%  reflect.addReflectOff         0     0%   100%        820   0.2%  git.sqcorp.co/cash/digester/lib/pkg/histogram.(*SlidingWindowDigest).Observe         0     0%   100%        820   0.2%  git.sqcorp.co/cash/digester/lib/pkg/histogram.(*SlidingWindowDigest).openDigests(pprof) cum(pprof) topShowing nodes accounting for 376842, 90.92% of 414485 totalShowing top 10 nodes out of 81      flat  flat%   sum%        cum   cum%         0     0%     0%     376842 90.92%  net/http/httptrace.(*ClientTrace).compose.func1         0     0%     0%     376842 90.92%  reflect.Value.Call         0     0%     0%     376842 90.92%  reflect.Value.call     32768  7.91%  7.91%     376842 90.92%  reflect.callReflect         0     0%  7.91%     376842 90.92%  reflect.makeFuncStub    344074 83.01% 90.92%     344074 83.01%  reflect.funcLayout.func1         0     0% 90.92%     344074 83.01%  sync.(*Pool).Get         0     0% 90.92%      16448  3.97%  github.com/json-iterator/go._createDecoderOfType         0     0% 90.92%      16448  3.97%  github.com/json-iterator/go.createDecoderOfType         0     0% 90.92%      16448  3.97%  github.com/json-iterator/go.decoderOfStructOn Mon, Jul 1, 2019 at 4:32 PM Robert Engels  wrote:A leak of the TCP connections (maybe not properly closed)? Each TCP connection will use kernel memory and process memory (local buffers), that won't be on the heap (the reference to the TCP connection will be in the Go heap, but is probably much smaller than the buffer allocation).That would be my guess - but just a guess.-Original Message-
From: 'Yunchi Luo' via golang-nuts 
Sent: Jul 1, 2019 2:14 PM
To: golang-nuts@googlegroups.com
Cc: Alec Thomas 
Subject: [go-nuts] OOM occurring with a small heap

Hello, I'd like to solicit some help with a weird GC issue we are seeing.I'm trying to debug OOM on a service we are running in k8s. The service is just a CRUD server hitting a database (DynamoDB). Each replica serves about 300 qps of traffic. There are no memory leaks. On 

Re: [go-nuts] using client-go and apimachinery with go modules

[Venkatesh Sundararaj]

Below works for me.

 k8s.io/api v0.0.0-20181221193117-173ce66c1e39
k8s.io/apimachinery v0.0.0-2019095121-fa6ddc151d63
k8s.io/client-go v10.0.0+incompatible

Regards,
Venky
On Mon, Jul 1, 2019 at 12:42 PM  wrote:

> Can anyone share a working go module file that gets client-go and
> apimachinery to play nicely? I tried letting go mod determine the versions
> and I get:
>
>
> k8s.io/apimachinery v0.0.0-20181127025237-2b1284ed4c93
> k8s.io/client-go v10.0.0+incompatible
>
>
> Which are incompatible and produce the error from here:
> https://github.com/kubernetes/client-go/issues/584.
>
> So I tried switching the apimachinery line in my go.mod to
>
>
> k8s.io/apimachinery v1.14.3
>
>
> But then I get:
>
>
> $ go build
> go: finding k8s.io/apimachinery v1.14.3
> go: k8s.io/apimachinery@v1.14.3: unknown revision v1.14.3
> go: error loading module requirements
>
>
> But that release exists here:
> https://github.com/kubernetes/apimachinery/releases/tag/kubernetes-1.14.3
>
> I also tried the below two options for apimachinery in go.mod which also
> both produced errors:
>
> k8s.io/apimachinery/kubernetes v1.14.3
> k8s.io/apimachinery kubernetes-v1.14.3
>
> --
> 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/d1cb3cba-3dbf-4cf9-b899-86e67419aa09%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALhoXtPfLY5a%3DXk-LWon61Vy97juoNPze2BYKbfKLtFr2kvL_Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] OOM occurring with a small heap

['Yunchi Luo' via golang-nuts]

I actually have a heap profile (pasted at the bottom) from about 1 second
before the service died (the goroutine that is logging "[Memory]" triggers
heap profiles once RSS > 100MB). I don't see TCP connections there. Maybe
it's too few to be sampled. How would I verify your theory? That the
service dies within 2 seconds after several hours makes it very hard to
debug.

The top thing in the heap profile is from the reflect package. I initially
found that suspect, but it turns out this comes from a use of
httptrace.ClientTrace I had for counting new connections to DynamoDB.

 tracer := {
   ConnectStart: func(_, _ string) {
 newConns.Inc()
   },
}

`newConns` is just a prometheus counter. The `tracer` object itself is
created once and re-used with every client request context. On request,
`httptrace.WithClientTrace(ctx, tracer)` uses reflection to compose the
trace functions under-the-hood and uses reflection to invoke it, hence the
reflect.funcLayout and reflect.Value.call. Objects in `reflect` account for
about 50% of heap in terms of size, and does seem to grow as the service is
running out of memory, but that's only 12MB so I thought it was a red
herring.

Heap profile:
Type: inuse_space
Time: Jun 30, 2019 at 4:46am (EDT)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) inuse_objects
(pprof) top
Showing nodes accounting for 414485, 100% of 414485 total
Showing top 10 nodes out of 81
  flat  flat%   sum%cum   cum%
344074 83.01% 83.01% 344074 83.01%  reflect.funcLayout.func1
 32768  7.91% 90.92% 376842 90.92%  reflect.callReflect
 16384  3.95% 94.87%  16384  3.95%
github.com/json-iterator/go.processTags
 10923  2.64% 97.51%  10923  2.64%  context.WithValue
  8192  1.98% 99.48%   8192  1.98%  crypto/hmac.New
  1260   0.3% 99.79%   1260   0.3%
github.com/aws/aws-sdk-go/aws/signer/v4.(*signingCtx).buildCanonicalHeaders
   820   0.2%   100%820   0.2%
github.com/stripe/veneur/tdigest.NewMerging
64 0.015%   100% 64 0.015%  reflect.addReflectOff
 0 0%   100%820   0.2%
git.sqcorp.co/cash/digester/lib/pkg/histogram.(*SlidingWindowDigest).Observe
 0 0%   100%820   0.2%
git.sqcorp.co/cash/digester/lib/pkg/histogram.(*SlidingWindowDigest).openDigests
(pprof) cum
(pprof) top
Showing nodes accounting for 376842, 90.92% of 414485 total
Showing top 10 nodes out of 81
  flat  flat%   sum%cum   cum%
 0 0% 0% 376842 90.92%
 net/http/httptrace.(*ClientTrace).compose.func1
 0 0% 0% 376842 90.92%  reflect.Value.Call
 0 0% 0% 376842 90.92%  reflect.Value.call
 32768  7.91%  7.91% 376842 90.92%  reflect.callReflect
 0 0%  7.91% 376842 90.92%  reflect.makeFuncStub
344074 83.01% 90.92% 344074 83.01%  reflect.funcLayout.func1
 0 0% 90.92% 344074 83.01%  sync.(*Pool).Get
 0 0% 90.92%  16448  3.97%
github.com/json-iterator/go._createDecoderOfType
 0 0% 90.92%  16448  3.97%
github.com/json-iterator/go.createDecoderOfType
 0 0% 90.92%  16448  3.97%
github.com/json-iterator/go.decoderOfStruct


On Mon, Jul 1, 2019 at 4:32 PM Robert Engels  wrote:

>
> A leak of the TCP connections (maybe not properly closed)? Each TCP
> connection will use kernel memory and process memory (local buffers), that
> won't be on the heap (the reference to the TCP connection will be in the Go
> heap, but is probably much smaller than the buffer allocation).
>
> That would be my guess - but just a guess.
>
> -Original Message-
> From: 'Yunchi Luo' via golang-nuts
> Sent: Jul 1, 2019 2:14 PM
> To: golang-nuts@googlegroups.com
> Cc: Alec Thomas
> Subject: [go-nuts] OOM occurring with a small heap
>
> Hello, I'd like to solicit some help with a weird GC issue we are seeing.
>
> I'm trying to debug OOM on a service we are running in k8s. The service is
> just a CRUD server hitting a database (DynamoDB). Each replica serves about
> 300 qps of traffic. There are no memory leaks. On occasion (seemingly
> correlated to small latency spikes on the backend), the service would OOM.
> This is surprising because it has a circuit breaker that drops requests
> after 200 concurrent connections that has never trips, and goroutine
> profiles confirm that there are nowhere 200 active goroutines.
>
> GC logs are pasted below. It's interlaced with dumps of runtime.Memstats
> (the RSS number is coming from /proc//stats). Go version is 1.12.5,
> running an Alpine 3.10 container in an Amazon kernel
> 4.14.123-111.109.amzn2.x86_64.
>
> The service happily serves requests using ~50MB of RSS for hours, until
> the last 2 seconds, where GC mark time starts to 2-4X per cycle 
> (43+489/158/0.60+0.021
> ms cpu => 43+489/158/0.60+0.021 ms cpu), and RSS and Sys blow up. It’s
> also interesting that in the last log line: `Sys=995MB RSS=861MB
> HeapSys=199MB`. If 

Re: [go-nuts] OOM occurring with a small heap

[Robert Engels]

A leak of the TCP connections (maybe not properly closed)? Each TCP connection will use kernel memory and process memory (local buffers), that won't be on the heap (the reference to the TCP connection will be in the Go heap, but is probably much smaller than the buffer allocation).That would be my guess - but just a guess.-Original Message-
From: 'Yunchi Luo' via golang-nuts 
Sent: Jul 1, 2019 2:14 PM
To: golang-nuts@googlegroups.com
Cc: Alec Thomas 
Subject: [go-nuts] OOM occurring with a small heap

Hello, I'd like to solicit some help with a weird GC issue we are seeing.I'm trying to debug OOM on a service we are running in k8s. The service is just a CRUD server hitting a database (DynamoDB). Each replica serves about 300 qps of traffic. There are no memory leaks. On occasion (seemingly correlated to small latency spikes on the backend), the service would OOM. This is surprising because it has a circuit breaker that drops requests after 200 concurrent connections that has never trips, and goroutine profiles confirm that there are nowhere 200 active goroutines.GC logs are pasted below. It's interlaced with dumps of runtime.Memstats (the RSS number is coming from /proc//stats). Go version is 1.12.5, running an Alpine 3.10 container in an Amazon kernel 4.14.123-111.109.amzn2.x86_64.The service happily serves requests using ~50MB of RSS for hours, until the last 2 seconds, where GC mark time starts to 2-4X per cycle (43+489/158/0.60+0.021 ms cpu => 43+489/158/0.60+0.021 ms cpu), and RSS and Sys blow up. It’s also interesting that in the last log line: `Sys=995MB RSS=861MB HeapSys=199MB`. If I’m reading this correctly, there’s at least `662MB` of memory in RSS that is not assigned to the heap. Though this might be due to the change in 1.125 to use MADV_FREE, so the pages are freeable not yet reclaimed by the kernel.I don’t understand how heap can be so small across gc cycles (28->42->30MB on the last line means heap doesn't grow past 42MB?), yet RSS keeps growing. I'm assuming the increased RSS is causing the kernel to OOM the service, but that should only happen if the RSS is not freeable as marked by MADV_FREE. There doesn't seem to be any indication of that from the GC logs. I guess this all comes down to me not having a good understanding of how the GC algorithm works and how to read these logs. I'd really appreciate it if anyone can explain what's happening and why.gc 41833 @19135.227s 0%: 0.019+2.3+0.005 ms clock, 0.079+0.29/2.2/5.6+0.020 ms cpu, 11->11->5 MB, 12 MB goal, 4 PINFO 2019-06-30T08:46:04.886 [Memory]: Alloc=7MB TotalAlloc=230172MB Sys=69MB RSS=51MB HeapSys=62MB HeapIdle=51MB HeapInUse=11MB HeapReleased=5MBgc 41834 @19135.869s 0%: 0.005+2.9+0.003 ms clock, 0.023+0.32/2.5/6.6+0.012 ms cpu, 11->11->5 MB, 12 MB goal, 4 PINFO 2019-06-30T08:46:05.886 [Memory]: Alloc=9MB TotalAlloc=230179MB Sys=69MB RSS=51MB HeapSys=62MB HeapIdle=50MB HeapInUse=12MB HeapReleased=5MBgc 41835 @19136.704s 0%: 0.038+2.1+0.004 ms clock, 0.15+0.35/2.1/5.3+0.016 ms cpu, 11->11->5 MB, 12 MB goal, 4 PINFO 2019-06-30T08:46:06.886 [Memory]: Alloc=9MB TotalAlloc=230184MB Sys=69MB RSS=51MB HeapSys=62MB HeapIdle=50MB HeapInUse=12MB HeapReleased=5MBgc 41836 @19137.611s 0%: 0.009+2.1+0.003 ms clock, 0.036+0.39/2.0/5.7+0.015 ms cpu, 11->11->5 MB, 12 MB goal, 4 PINFO 2019-06-30T08:46:07.887 [Memory]: Alloc=10MB TotalAlloc=230190MB Sys=69MB RSS=51MB HeapSys=62MB HeapIdle=49MB HeapInUse=12MB HeapReleased=5MBgc 41837 @19138.444s 0%: 0.008+2.1+0.004 ms clock, 0.035+0.51/2.1/5.7+0.017 ms cpu, 11->11->5 MB, 12 MB goal, 4 PINFO 2019-06-30T08:46:08.887 [Memory]: Alloc=10MB TotalAlloc=230195MB Sys=69MB RSS=51MB HeapSys=62MB HeapIdle=49MB HeapInUse=12MB HeapReleased=5MBgc 41838 @19139.474s 0%: 0.005+2.6+0.003 ms clock, 0.023+0.37/2.5/4.3+0.014 ms cpu, 11->11->5 MB, 12 MB goal, 4 Pgc 41839 @19140.173s 0%: 0.011+2.4+0.003 ms clock, 0.046+0.20/2.3/5.8+0.015 ms cpu, 11->11->5 MB, 12 MB goal, 4 PINFO 2019-06-30T08:46:09.887 [Memory]: Alloc=7MB TotalAlloc=230202MB Sys=69MB RSS=51MB HeapSys=62MB HeapIdle=50MB HeapInUse=11MB HeapReleased=5MBgc 41840 @19140.831s 0%: 0.082+2.1+0.003 ms clock, 0.32+0.64/2.1/5.3+0.014 ms cpu, 11->11->5 MB, 12 MB goal, 4 PINFO 2019-06-30T08:46:10.887 [Memory]: Alloc=9MB TotalAlloc=230209MB Sys=69MB RSS=51MB HeapSys=62MB HeapIdle=50MB HeapInUse=12MB HeapReleased=5MBgc 41841 @19141.655s 0%: 0.014+2.1+0.003 ms clock, 0.056+0.28/2.0/5.7+0.013 ms cpu, 11->11->5 MB, 12 MB goal, 4 Pgc 41842 @19142.316s 0%: 0.006+2.7+0.003 ms clock, 0.027+0.29/2.6/6.2+0.014 ms cpu, 11->11->5 MB, 12 MB goal, 4 PINFO 2019-06-30T08:46:11.888 [Memory]: Alloc=6MB TotalAlloc=230216MB Sys=69MB RSS=51MB HeapSys=62MB HeapIdle=51MB HeapInUse=11MB HeapReleased=5MBgc 41843 @19142.942s 0%: 0.010+2.1+0.005 ms clock, 0.040+0.29/2.0/5.7+0.023 ms cpu, 11->11->5 MB, 12 MB goal, 4 PINFO 2019-06-30T08:46:12.888 [Memory]: Alloc=9MB TotalAlloc=230223MB Sys=69MB RSS=51MB HeapSys=62MB HeapIdle=50MB HeapInUse=11MB HeapReleased=5MBgc 41844 @19143.724s 0%: 

[go-nuts] Reflection: How to retrieve index of map

[Mark Bauermeister]

I have the following code, where the TokenMap struct is actually part of 
another package. 
idMap is not exported and thus not accessible without reflection.

Through reflection I can easily find the value of "int", which is "28".
Now, I'd like to do the opposite though. I'd like to find "28"'s index (i e 
"int").

How would I go about that?

https://play.golang.org/p/UnMi4gQGrIr

-- 
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/844522f8-145c-44c1-b382-338c2936d5fb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go list returning directory starting with underscore on Ubuntu

[ufuk . okuyucu]

Seeing paths that begin with "_" in the go list output means those modules 
are not in your GOPATH. In my case, I was collecting list of modules in a 
subshell (i.e. $(shell)) which doesn't have my GOPATH. If I run my go list 
command via backtick then it can use the global GOPATH define and works 
fine.

On Tuesday, January 8, 2019 at 12:17:01 PM UTC-8, tatsuy...@nftlearning.com 
wrote:
>
> I don't know it helps as I'm on zshell.  I replaced 
> `GOPATH=~/works/golang` with `export GOPATH=~/works/golang`. then, it fixed.
>
>
>
> Before
>
> % go list ./server/...
>
> _/Users/myuser/works/golang/src/mattermost-plugin-dialect/src/server
>
>
> After
> % go list ./server/...
>
> mattermost-plugin-dialect/src/server
>
>
> On Wednesday, 21 November 2018 21:09:29 UTC+1, ipob...@kdu.cl wrote:
>>
>> Hi, I have the same problem, but I just want to scan my custom packages, 
>> when I do the go list. / ... it returns the correct routes, but with the 
>> underscore at the beginning of the routes, it is worth noting that the 
>> project does not have it inside the $ GOPATH (my $ GOPATH is in $ HOME / go)
>>
>> El jueves, 1 de marzo de 2018, 14:22:43 (UTC-3), Michel Hollands escribió:
>>>
>>> Hello,
>>>
>>> When running go list on Ubuntu the results are weird:
>>>
>>> michel@michel-VirtualBox:~/git/grpcurl$ go list .
>>> _/home/michel/git/grpcurl
>>> michel@michel-VirtualBox:~/git/grpcurl$ 
>>>
>>> Running the same on the Mac returns just grpcurl, which is the correct 
>>> package.
>>>
>>> The Go version is: 
>>>
>>> go version go1.10 linux/amd64
>>>
>>> The Ubuntu is 16.04.4 LTS which was freshly installed.
>>>
>>> Any ideas about what could be wrong?
>>>
>>> Thanks in advance,
>>>
>>> Michel
>>>
>>>

-- 
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/44e92256-0ae8-41a1-81a1-3651d8d68797%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] OOM occurring with a small heap

['Yunchi Luo' via golang-nuts]

Hello, I'd like to solicit some help with a weird GC issue we are seeing.

I'm trying to debug OOM on a service we are running in k8s. The service is
just a CRUD server hitting a database (DynamoDB). Each replica serves about
300 qps of traffic. There are no memory leaks. On occasion (seemingly
correlated to small latency spikes on the backend), the service would OOM.
This is surprising because it has a circuit breaker that drops requests
after 200 concurrent connections that has never trips, and goroutine
profiles confirm that there are nowhere 200 active goroutines.

GC logs are pasted below. It's interlaced with dumps of runtime.Memstats
(the RSS number is coming from /proc//stats). Go version is 1.12.5,
running an Alpine 3.10 container in an Amazon kernel
4.14.123-111.109.amzn2.x86_64.

The service happily serves requests using ~50MB of RSS for hours, until the
last 2 seconds, where GC mark time starts to 2-4X per cycle
(43+489/158/0.60+0.021
ms cpu => 43+489/158/0.60+0.021 ms cpu), and RSS and Sys blow up. It’s also
interesting that in the last log line: `Sys=995MB RSS=861MB HeapSys=199MB`.
If I’m reading this correctly, there’s at least `662MB` of memory in RSS
that is not assigned to the heap. Though this might be due to the change in
1.125 to use MADV_FREE, so the pages are freeable not yet reclaimed by the
kernel.

I don’t understand how heap can be so small across gc cycles (28->42->30MB
on the last line means heap doesn't grow past 42MB?), yet RSS keeps
growing. I'm assuming the increased RSS is causing the kernel to OOM the
service, but that should only happen if the RSS is not freeable as marked
by MADV_FREE. There doesn't seem to be any indication of that from the GC
logs. I guess this all comes down to me not having a good understanding of
how the GC algorithm works and how to read these logs. I'd really
appreciate it if anyone can explain what's happening and why.

gc 41833 @19135.227s 0%: 0.019+2.3+0.005 ms clock, 0.079+0.29/2.2/5.6+0.020
ms cpu, 11->11->5 MB, 12 MB goal, 4 P
INFO 2019-06-30T08:46:04.886 [Memory]: Alloc=7MB TotalAlloc=230172MB
Sys=69MB RSS=51MB HeapSys=62MB HeapIdle=51MB HeapInUse=11MB HeapReleased=5MB
gc 41834 @19135.869s 0%: 0.005+2.9+0.003 ms clock, 0.023+0.32/2.5/6.6+0.012
ms cpu, 11->11->5 MB, 12 MB goal, 4 P
INFO 2019-06-30T08:46:05.886 [Memory]: Alloc=9MB TotalAlloc=230179MB
Sys=69MB RSS=51MB HeapSys=62MB HeapIdle=50MB HeapInUse=12MB HeapReleased=5MB
gc 41835 @19136.704s 0%: 0.038+2.1+0.004 ms clock, 0.15+0.35/2.1/5.3+0.016
ms cpu, 11->11->5 MB, 12 MB goal, 4 P
INFO 2019-06-30T08:46:06.886 [Memory]: Alloc=9MB TotalAlloc=230184MB
Sys=69MB RSS=51MB HeapSys=62MB HeapIdle=50MB HeapInUse=12MB HeapReleased=5MB
gc 41836 @19137.611s 0%: 0.009+2.1+0.003 ms clock, 0.036+0.39/2.0/5.7+0.015
ms cpu, 11->11->5 MB, 12 MB goal, 4 P
INFO 2019-06-30T08:46:07.887 [Memory]: Alloc=10MB TotalAlloc=230190MB
Sys=69MB RSS=51MB HeapSys=62MB HeapIdle=49MB HeapInUse=12MB HeapReleased=5MB
gc 41837 @19138.444s 0%: 0.008+2.1+0.004 ms clock, 0.035+0.51/2.1/5.7+0.017
ms cpu, 11->11->5 MB, 12 MB goal, 4 P
INFO 2019-06-30T08:46:08.887 [Memory]: Alloc=10MB TotalAlloc=230195MB
Sys=69MB RSS=51MB HeapSys=62MB HeapIdle=49MB HeapInUse=12MB HeapReleased=5MB
gc 41838 @19139.474s 0%: 0.005+2.6+0.003 ms clock, 0.023+0.37/2.5/4.3+0.014
ms cpu, 11->11->5 MB, 12 MB goal, 4 P
gc 41839 @19140.173s 0%: 0.011+2.4+0.003 ms clock, 0.046+0.20/2.3/5.8+0.015
ms cpu, 11->11->5 MB, 12 MB goal, 4 P
INFO 2019-06-30T08:46:09.887 [Memory]: Alloc=7MB TotalAlloc=230202MB
Sys=69MB RSS=51MB HeapSys=62MB HeapIdle=50MB HeapInUse=11MB HeapReleased=5MB
gc 41840 @19140.831s 0%: 0.082+2.1+0.003 ms clock, 0.32+0.64/2.1/5.3+0.014
ms cpu, 11->11->5 MB, 12 MB goal, 4 P
INFO 2019-06-30T08:46:10.887 [Memory]: Alloc=9MB TotalAlloc=230209MB
Sys=69MB RSS=51MB HeapSys=62MB HeapIdle=50MB HeapInUse=12MB HeapReleased=5MB
gc 41841 @19141.655s 0%: 0.014+2.1+0.003 ms clock, 0.056+0.28/2.0/5.7+0.013
ms cpu, 11->11->5 MB, 12 MB goal, 4 P
gc 41842 @19142.316s 0%: 0.006+2.7+0.003 ms clock, 0.027+0.29/2.6/6.2+0.014
ms cpu, 11->11->5 MB, 12 MB goal, 4 P
INFO 2019-06-30T08:46:11.888 [Memory]: Alloc=6MB TotalAlloc=230216MB
Sys=69MB RSS=51MB HeapSys=62MB HeapIdle=51MB HeapInUse=11MB HeapReleased=5MB
gc 41843 @19142.942s 0%: 0.010+2.1+0.005 ms clock, 0.040+0.29/2.0/5.7+0.023
ms cpu, 11->11->5 MB, 12 MB goal, 4 P
INFO 2019-06-30T08:46:12.888 [Memory]: Alloc=9MB TotalAlloc=230223MB
Sys=69MB RSS=51MB HeapSys=62MB HeapIdle=50MB HeapInUse=11MB HeapReleased=5MB
gc 41844 @19143.724s 0%: 0.008+2.4+0.004 ms clock, 0.035+0.38/2.0/5.7+0.017
ms cpu, 11->11->5 MB, 12 MB goal, 4 P
gc 41845 @19144.380s 0%: 10+9.3+0.044 ms clock, 43+6.1/9.2/4.4+0.17 ms cpu,
11->11->6 MB, 12 MB goal, 4 P
INFO 2019-06-30T08:46:13.901 [Memory]: Alloc=6MB TotalAlloc=230230MB
Sys=136MB RSS=98MB HeapSys=94MB HeapIdle=83MB HeapInUse=11MB
HeapReleased=35MB
gc 41846 @19144.447s 0%: 0.008+26+0.005 ms clock, 0.033+0.46/7.8/26+0.020
ms cpu, 11->12->9 MB, 12 MB goal, 4 P
gc 41847 @19144.672s 0%: 

Re: [go-nuts] goforward: What is it? How do I use it?

[aoneal]

> In terms of how you get it, when you go to 
> https://go-review.googlesource.com/c/tools/+/137076/, you should see a 
> 'Download' button on the right side. If you click on that, it gives you 4-5 
> options ranging from 'git fetch' to downloading a zip.
>

I did not see that before. Odd that they put it over on the right by the 
message history rather than on the left by the code history.

Thanks for sharing the output of the help too.

I'm not confident that there is now more documentation in this thread in 
regards to go forward than there is anywhere else on the web.

:)

-- 
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/84040d47-a88a-49c6-8ebb-50d51f50f8ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: .editorconfig for golang projects & github pr automated gofmt checks

[tgoshinski]

[*.go]
indent_size = 4
indent_style = tab


>From my base .editorconfig

On Monday, July 1, 2019 at 10:54:29 AM UTC-5, Sankar wrote:
>
> Hi
>
> We use github for our sources. Developers are free to choose their IDEs 
> and tools. Sometimes, people end up committing sources using spaces instead 
> of tabs, etc. Not all developers do goimports/gofmt on save. So, we want to 
> automate this process. However, instead of adding git pre-commit hooks, we 
> want to have this done only when people raise a github PR. Have any of you 
> done this in your project and shared your experience in a blog / writeup ? 
> Please let us know. Googling would still be done for this, but wanted to 
> ask in this list also.
>
> Another somewhat related query is, we are also considering adding a 
> .editorconfig for our Golang projects. Are there any standard .editorconfig 
> settings for *.go that you use ?
>
> 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/1af6b367-4f50-4369-87e8-84cd294fc15a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] using client-go and apimachinery with go modules

[raphaeldeem]

Can anyone share a working go module file that gets client-go and 
apimachinery to play nicely? I tried letting go mod determine the versions 
and I get:


k8s.io/apimachinery v0.0.0-20181127025237-2b1284ed4c93
k8s.io/client-go v10.0.0+incompatible


Which are incompatible and produce the error from here: 
https://github.com/kubernetes/client-go/issues/584. 

So I tried switching the apimachinery line in my go.mod to 


k8s.io/apimachinery v1.14.3


But then I get:


$ go build
go: finding k8s.io/apimachinery v1.14.3
go: k8s.io/apimachinery@v1.14.3: unknown revision v1.14.3
go: error loading module requirements


But that release exists here: 
https://github.com/kubernetes/apimachinery/releases/tag/kubernetes-1.14.3

I also tried the below two options for apimachinery in go.mod which also 
both produced errors:

k8s.io/apimachinery/kubernetes v1.14.3
k8s.io/apimachinery kubernetes-v1.14.3

-- 
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/d1cb3cba-3dbf-4cf9-b899-86e67419aa09%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Engels]

I never disputed that there were (in both camps). I disputed the original argument that preferring the input of people with extensive Go experience, over minimal Go experience was a valid approach, and argued that approach was short-sighted and error prone (for the reasons cited).Not to fan any unrelated flames, but I would rank experience > wits > education. Ideally you have an abundance of all three, but only the first and last have a time component (and by experience I am referring to expert experience, as in an 'expert plumber'), but its also very hard to get the first, without the other two.-Original Message-
From: Henrik Johansson 
Sent: Jul 1, 2019 1:22 PM
To: robert engels 
Cc: David Suarez , golang-nuts 
Subject: Re: [go-nuts] Re: The "leave "if err != nil" alone?" anti-proposal

I am not making this argument but you are continuously referring to experienced developer's preferences (perhaps someone else more if so I am sorry).Don't get me wrong. Experience is good and weigh a lot especially combined with education and wits. Perhaps we can both concede that there are such developers in both camps.On Mon, Jul 1, 2019, 19:21 Robert Engels  wrote:I don't think that has anything to do with what I said.I stated that experienced developers with minimal Go experience can probably offer deeper insights than new developers with only Go experience.The Go team is experienced developers (at least the ones I know), AND have deep Go experience (I am assuming - but maybe not on the Go application vs internal development side).If you are making the claim that the Go team "knows all", then why even have these conversations in the first place? Why have any community involvement at all? I am pretty sure this is not the position of the "Go team".-Original Message-
From: Henrik Johansson 
Sent: Jul 1, 2019 12:14 PM
To: robert engels 
Cc: David Suarez , golang-nuts 
Subject: Re: [go-nuts] Re: The "leave "if err != nil" alone?" anti-proposal

This is funny since you are perfectly describing the Go core team... ;)I really can't get my head around it that this topic generates so much vitriol (maybe harsh).Generics I kinda get but this is just incredible.Don't like try? Don't use it.On Mon, Jul 1, 2019, 18:42 Robert Engels  wrote:I think that is going to suffer greatly from sampling bias.You may have an engineer with 20+ years of programming in a variety of languages - using both exceptions, and error values, and be new to Go, but still have substantial insight as to the relative merits and drawbacks of proposed options.In fact, I would argue that it is these experienced engineers that can foretell the "end result" of various paths with far greater accuracy than a new developer with multiple years of nothing but Go experience.Nothing is new, it is an impedance matching exercise.-Original Message-
From: David Suarez 
Sent: Jul 1, 2019 11:16 AM
To: golang-nuts 
Subject: [go-nuts] Re: The "leave "if err != nil" alone?" anti-proposal

The number of posts on this topic piqued my curiosity so I hope to add some considerations after doing some research on this trail that I hope you find useful.TL;DR:  It is possible that the reason for the interest in improving "exception handling" in the proposed way is driven by individuals that are not yet fully comfortable in the languageFrom what I have gathered, the reason for improving this area was due to a Go Survey.  This reminds me of this popular quote:Quote. “If I had asked people what they wanted, they would have said faster horses.”  Henry Ford, Innovation, Please note that while I did not participate in the survey, I would probably have said the same thing until I got "used to it".  The interesting support bit from the survey was the answer to, "I have used Go for..."  -  suggests that 1/3rd of the respondents have only 1 year experience or less with the language and a full half have less than 2 years experience. In my experience, when I started Go I was (and still am in some cases) using some Java paradigms in them that make sense to me which is great for transition but may not be great for the language long runI am sure folks that have been around a while would agree that some of the reasons they are considering or actively changing languages tend to be due to bloat and unnecessary features that eventually weigh down productivity because there are 10 ways to skin the cat and everyone has a different opinion due to either how the rest of the code base does it or what is new.  The large response to this thread suggests that potentially there may be a better feature out there that merits some attention and I would suggest it may be something that should come from the 2+ years experience crowd (if weighting of the results is possible) as those are likely the challenges that newbies like me will eventually encounter.  Weighing the survey results by experience may help Go stay ahead of the curve.  Just my .02**  

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

[Henrik Johansson]

I am not making this argument but you are continuously referring to
experienced developer's preferences (perhaps someone else more if so I am
sorry).

Don't get me wrong. Experience is good and weigh a lot especially combined
with education and wits. Perhaps we can both concede that there are such
developers in both camps.

On Mon, Jul 1, 2019, 19:21 Robert Engels  wrote:

>
> I don't think that has anything to do with what I said.
>
> I stated that experienced developers with minimal Go experience can
> probably offer deeper insights than new developers with only Go experience.
>
> The Go team is experienced developers (at least the ones I know), AND have
> deep Go experience (I am assuming - but maybe not on the Go application vs
> internal development side).
>
> If you are making the claim that the Go team "knows all", then why even
> have these conversations in the first place? Why have any community
> involvement at all? I am pretty sure this is not the position of the "Go
> team".
>
> -Original Message-
> From: Henrik Johansson
> Sent: Jul 1, 2019 12:14 PM
> To: robert engels
> Cc: David Suarez , golang-nuts
> Subject: Re: [go-nuts] Re: The "leave "if err != nil" alone?"
> anti-proposal
>
> This is funny since you are perfectly describing the Go core team... ;)
>
> I really can't get my head around it that this topic generates so much
> vitriol (maybe harsh).
> Generics I kinda get but this is just incredible.
> Don't like try? Don't use it.
>
> On Mon, Jul 1, 2019, 18:42 Robert Engels  wrote:
>
>> I think that is going to suffer greatly from sampling bias.
>>
>> You may have an engineer with 20+ years of programming in a variety of
>> languages - using both exceptions, and error values, and be new to Go, but
>> still have substantial insight as to the relative merits and drawbacks of
>> proposed options.
>>
>> In fact, I would argue that it is these experienced engineers that can
>> foretell the "end result" of various paths with far greater accuracy than a
>> new developer with multiple years of nothing but Go experience.
>>
>> Nothing is new, it is an impedance matching exercise.
>>
>>
>> -Original Message-
>> From: David Suarez
>> Sent: Jul 1, 2019 11:16 AM
>> To: golang-nuts
>> Subject: [go-nuts] Re: The "leave "if err != nil" alone?" anti-proposal
>>
>> The number of posts on this topic piqued my curiosity so I hope to add
>> some considerations after doing some research on this trail that I hope you
>> find useful.
>>
>> TL;DR:  It is possible that the reason for the interest in improving
>> "exception handling" in the proposed way is driven by individuals that are
>> not yet fully comfortable in the language
>>
>> From what I have gathered, the reason for improving this area was due to
>> a Go Survey.  This reminds me of this popular quote:
>> Quote. “*If* I had *asked* people what *they wanted*, *they* would have
>> said faster horses.”  Henry Ford, Innovation,
>>
>> Please note that while I did not participate in the survey, I would
>> probably have said the same thing until I got "used to it".  The
>> interesting support bit from the survey was the answer to, "I have used Go
>> for..."  -  suggests that 1/3rd of the respondents have only 1 year
>> experience or less with the language and a full half have less than 2 years
>> experience. In my experience, when I started Go I was (and still am in some
>> cases) using some Java paradigms in them that make sense to me which is
>> great for transition but may not be great for the language long run
>>
>> I am sure folks that have been around a while would agree that some of
>> the reasons they are considering or actively changing languages tend to be
>> due to bloat and unnecessary features that eventually weigh down
>> productivity because there are 10 ways to skin the cat and everyone has a
>> different opinion due to either how the rest of the code base does it or
>> what is new.
>>
>> The large response to this thread suggests that potentially there may be
>> a better feature out there that merits some attention and I would suggest
>> it may be something that should come from the 2+ years experience crowd (if
>> weighting of the results is possible) as those are likely the challenges
>> that newbies like me will eventually encounter.  Weighing the survey
>> results by experience may help Go stay ahead of the curve.  Just my .02
>>
>> **  Side note:  I am a relative newcomer to Go (~8-9 months) so there is
>> likely some bias there from my newness.  Add salt here
>>
>> On Friday, June 28, 2019 at 7:44:01 PM UTC-5, Tyler Compton wrote:
>>>
>>> If anyone hasn't seen it, an issue with the "proposal" tag was created
>>> earlier on the Go issue tracker titled "Proposal: leave "if err != nil"
>>> alone?" (here ). This issue seems to
>>> have resonated with a lot of people, which may be an important data point
>>> when considering the try proposal ,
>>> but I was 

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

[Robert Engels]

I don't think that has anything to do with what I said.I stated that experienced developers with minimal Go experience can probably offer deeper insights than new developers with only Go experience.The Go team is experienced developers (at least the ones I know), AND have deep Go experience (I am assuming - but maybe not on the Go application vs internal development side).If you are making the claim that the Go team "knows all", then why even have these conversations in the first place? Why have any community involvement at all? I am pretty sure this is not the position of the "Go team".-Original Message-
From: Henrik Johansson 
Sent: Jul 1, 2019 12:14 PM
To: robert engels 
Cc: David Suarez , golang-nuts 
Subject: Re: [go-nuts] Re: The "leave "if err != nil" alone?" anti-proposal

This is funny since you are perfectly describing the Go core team... ;)I really can't get my head around it that this topic generates so much vitriol (maybe harsh).Generics I kinda get but this is just incredible.Don't like try? Don't use it.On Mon, Jul 1, 2019, 18:42 Robert Engels  wrote:I think that is going to suffer greatly from sampling bias.You may have an engineer with 20+ years of programming in a variety of languages - using both exceptions, and error values, and be new to Go, but still have substantial insight as to the relative merits and drawbacks of proposed options.In fact, I would argue that it is these experienced engineers that can foretell the "end result" of various paths with far greater accuracy than a new developer with multiple years of nothing but Go experience.Nothing is new, it is an impedance matching exercise.-Original Message-
From: David Suarez 
Sent: Jul 1, 2019 11:16 AM
To: golang-nuts 
Subject: [go-nuts] Re: The "leave "if err != nil" alone?" anti-proposal

The number of posts on this topic piqued my curiosity so I hope to add some considerations after doing some research on this trail that I hope you find useful.TL;DR:  It is possible that the reason for the interest in improving "exception handling" in the proposed way is driven by individuals that are not yet fully comfortable in the languageFrom what I have gathered, the reason for improving this area was due to a Go Survey.  This reminds me of this popular quote:Quote. “If I had asked people what they wanted, they would have said faster horses.”  Henry Ford, Innovation, Please note that while I did not participate in the survey, I would probably have said the same thing until I got "used to it".  The interesting support bit from the survey was the answer to, "I have used Go for..."  -  suggests that 1/3rd of the respondents have only 1 year experience or less with the language and a full half have less than 2 years experience. In my experience, when I started Go I was (and still am in some cases) using some Java paradigms in them that make sense to me which is great for transition but may not be great for the language long runI am sure folks that have been around a while would agree that some of the reasons they are considering or actively changing languages tend to be due to bloat and unnecessary features that eventually weigh down productivity because there are 10 ways to skin the cat and everyone has a different opinion due to either how the rest of the code base does it or what is new.  The large response to this thread suggests that potentially there may be a better feature out there that merits some attention and I would suggest it may be something that should come from the 2+ years experience crowd (if weighting of the results is possible) as those are likely the challenges that newbies like me will eventually encounter.  Weighing the survey results by experience may help Go stay ahead of the curve.  Just my .02**  Side note:  I am a relative newcomer to Go (~8-9 months) so there is likely some bias there from my newness.  Add salt hereOn Friday, June 28, 2019 at 7:44:01 PM UTC-5, Tyler Compton wrote:If anyone hasn't seen it, an issue with the "proposal" tag was created earlier on the Go issue tracker titled "Proposal: leave "if err != nil" alone?" (here). This issue seems to have resonated with a lot of people, which may be an important data point when considering the try proposal, but I was surprised to see how poorly the discussion has gone. There are quite a few "me too" comments, a few image-only posts, some less than stellar personal conduct, and overall not a lot of nuanced discussion. I feel that perhaps these kinds of anti-proposals should be discouraged because they're inherently reactionary, which seems to get the discussion off on the wrong foot.That said, this anti-proposal attracted a whole new group of Go users that I don't remember from the original try proposal discussion, which was mostly dominated by ten or twenty participants. The discussion was better, but the number of active users was much smaller. I wonder if there's a way to better engage a larger portion of the Go 

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

[Henrik Johansson]

This is funny since you are perfectly describing the Go core team... ;)

I really can't get my head around it that this topic generates so much
vitriol (maybe harsh).
Generics I kinda get but this is just incredible.
Don't like try? Don't use it.

On Mon, Jul 1, 2019, 18:42 Robert Engels  wrote:

> I think that is going to suffer greatly from sampling bias.
>
> You may have an engineer with 20+ years of programming in a variety of
> languages - using both exceptions, and error values, and be new to Go, but
> still have substantial insight as to the relative merits and drawbacks of
> proposed options.
>
> In fact, I would argue that it is these experienced engineers that can
> foretell the "end result" of various paths with far greater accuracy than a
> new developer with multiple years of nothing but Go experience.
>
> Nothing is new, it is an impedance matching exercise.
>
>
> -Original Message-
> From: David Suarez
> Sent: Jul 1, 2019 11:16 AM
> To: golang-nuts
> Subject: [go-nuts] Re: The "leave "if err != nil" alone?" anti-proposal
>
> The number of posts on this topic piqued my curiosity so I hope to add
> some considerations after doing some research on this trail that I hope you
> find useful.
>
> TL;DR:  It is possible that the reason for the interest in improving
> "exception handling" in the proposed way is driven by individuals that are
> not yet fully comfortable in the language
>
> From what I have gathered, the reason for improving this area was due to a
> Go Survey.  This reminds me of this popular quote:
> Quote. “*If* I had *asked* people what *they wanted*, *they* would have
> said faster horses.”  Henry Ford, Innovation,
>
> Please note that while I did not participate in the survey, I would
> probably have said the same thing until I got "used to it".  The
> interesting support bit from the survey was the answer to, "I have used Go
> for..."  -  suggests that 1/3rd of the respondents have only 1 year
> experience or less with the language and a full half have less than 2 years
> experience. In my experience, when I started Go I was (and still am in some
> cases) using some Java paradigms in them that make sense to me which is
> great for transition but may not be great for the language long run
>
> I am sure folks that have been around a while would agree that some of the
> reasons they are considering or actively changing languages tend to be due
> to bloat and unnecessary features that eventually weigh down productivity
> because there are 10 ways to skin the cat and everyone has a different
> opinion due to either how the rest of the code base does it or what is
> new.
>
> The large response to this thread suggests that potentially there may be a
> better feature out there that merits some attention and I would suggest it
> may be something that should come from the 2+ years experience crowd (if
> weighting of the results is possible) as those are likely the challenges
> that newbies like me will eventually encounter.  Weighing the survey
> results by experience may help Go stay ahead of the curve.  Just my .02
>
> **  Side note:  I am a relative newcomer to Go (~8-9 months) so there is
> likely some bias there from my newness.  Add salt here
>
> On Friday, June 28, 2019 at 7:44:01 PM UTC-5, Tyler Compton wrote:
>>
>> If anyone hasn't seen it, an issue with the "proposal" tag was created
>> earlier on the Go issue tracker titled "Proposal: leave "if err != nil"
>> alone?" (here ). This issue seems to
>> have resonated with a lot of people, which may be an important data point
>> when considering the try proposal , but
>> I was surprised to see how poorly the discussion has gone. There are quite
>> a few "me too" comments, a few image-only posts, some less than stellar
>> personal conduct, and overall not a lot of nuanced discussion. I feel that
>> perhaps these kinds of anti-proposals should be discouraged because they're
>> inherently reactionary, which seems to get the discussion off on the wrong
>> foot.
>>
>> That said, this anti-proposal attracted a whole new group of Go users
>> that I don't remember from the original try proposal discussion, which was
>> mostly dominated by ten or twenty participants. The discussion was better,
>> but the number of active users was much smaller. I wonder if there's a way
>> to better engage a larger portion of the Go user base while still
>> encouraging healthy, technical discussion.
>>
> --
> 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/1284af52-5fd6-4cd0-9bd3-cc69fd1c2fc7%40googlegroups.com
> 

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

[Robert Engels]

I think that is going to suffer greatly from sampling bias.You may have an engineer with 20+ years of programming in a variety of languages - using both exceptions, and error values, and be new to Go, but still have substantial insight as to the relative merits and drawbacks of proposed options.In fact, I would argue that it is these experienced engineers that can foretell the "end result" of various paths with far greater accuracy than a new developer with multiple years of nothing but Go experience.Nothing is new, it is an impedance matching exercise.-Original Message-
From: David Suarez 
Sent: Jul 1, 2019 11:16 AM
To: golang-nuts 
Subject: [go-nuts] Re: The "leave "if err != nil" alone?" anti-proposal

The number of posts on this topic piqued my curiosity so I hope to add some considerations after doing some research on this trail that I hope you find useful.TL;DR:  It is possible that the reason for the interest in improving "exception handling" in the proposed way is driven by individuals that are not yet fully comfortable in the languageFrom what I have gathered, the reason for improving this area was due to a Go Survey.  This reminds me of this popular quote:Quote. “If I had asked people what they wanted, they would have said faster horses.”  Henry Ford, Innovation, Please note that while I did not participate in the survey, I would probably have said the same thing until I got "used to it".  The interesting support bit from the survey was the answer to, "I have used Go for..."  -  suggests that 1/3rd of the respondents have only 1 year experience or less with the language and a full half have less than 2 years experience. In my experience, when I started Go I was (and still am in some cases) using some Java paradigms in them that make sense to me which is great for transition but may not be great for the language long runI am sure folks that have been around a while would agree that some of the reasons they are considering or actively changing languages tend to be due to bloat and unnecessary features that eventually weigh down productivity because there are 10 ways to skin the cat and everyone has a different opinion due to either how the rest of the code base does it or what is new.  The large response to this thread suggests that potentially there may be a better feature out there that merits some attention and I would suggest it may be something that should come from the 2+ years experience crowd (if weighting of the results is possible) as those are likely the challenges that newbies like me will eventually encounter.  Weighing the survey results by experience may help Go stay ahead of the curve.  Just my .02**  Side note:  I am a relative newcomer to Go (~8-9 months) so there is likely some bias there from my newness.  Add salt hereOn Friday, June 28, 2019 at 7:44:01 PM UTC-5, Tyler Compton wrote:If anyone hasn't seen it, an issue with the "proposal" tag was created earlier on the Go issue tracker titled "Proposal: leave "if err != nil" alone?" (here). This issue seems to have resonated with a lot of people, which may be an important data point when considering the try proposal, but I was surprised to see how poorly the discussion has gone. There are quite a few "me too" comments, a few image-only posts, some less than stellar personal conduct, and overall not a lot of nuanced discussion. I feel that perhaps these kinds of anti-proposals should be discouraged because they're inherently reactionary, which seems to get the discussion off on the wrong foot.That said, this anti-proposal attracted a whole new group of Go users that I don't remember from the original try proposal discussion, which was mostly dominated by ten or twenty participants. The discussion was better, but the number of active users was much smaller. I wonder if there's a way to better engage a larger portion of the Go user base while still encouraging healthy, technical discussion.




-- 
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/1284af52-5fd6-4cd0-9bd3-cc69fd1c2fc7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.




-- 
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/974016176.5469.1561999325924%40wamui-cheeto.atl.sa.earthlink.net.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] recover from a unexpected fault address

[Robert Engels]

They are almost certainly caused by a 1) bug in Go, 2) improper use of CGO, 3) improper use of unsafe.With 3 being most likely, and most likely caused by overwriting memory buffers.You don't want to recover from these - need to fix the source of the problem. If you included more of the stack trace it might give a better idea of the cause of the problem.-Original Message-
From: Mayank Jha 
Sent: Jul 1, 2019 11:03 AM
To: golang-nuts 
Subject: [go-nuts] recover from a unexpected fault address

unexpected fault address 0x0fatal error: fault[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0xd9c026]goroutine 11707890 [running]:runtime.throw(0x13c74b7, 0x5)	/usr/local/go/src/runtime/panic.go:617 +0x72 fp=0xc0080ac5f0 sp=0xc0080ac5c0 pc=0x42f5c2runtime.sigpanic()	/usr/local/go/src/runtime/signal_unix.go:397 +0x401 fp=0xc0080ac620 sp=0xc0080ac5f0 pc=0x444cf1Is there a way one can recover from such errors ? when does such error happen ? Any ideas ?



-- 
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/7959bb0d-de87-49ae-828c-d3e02e062d7d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.




-- 
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/2045865953.5343.1561998950210%40wamui-cheeto.atl.sa.earthlink.net.
For more options, visit https://groups.google.com/d/optout.

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

[David Suarez]

The number of posts on this topic piqued my curiosity so I hope to add some 
considerations after doing some research on this trail that I hope you find 
useful.

TL;DR:  It is possible that the reason for the interest in improving 
"exception handling" in the proposed way is driven by individuals that are 
not yet fully comfortable in the language

>From what I have gathered, the reason for improving this area was due to a 
Go Survey.  This reminds me of this popular quote:
Quote. “*If* I had *asked* people what *they wanted*, *they* would have 
said faster horses.”  Henry Ford, Innovation, 

Please note that while I did not participate in the survey, I would 
probably have said the same thing until I got "used to it".  The 
interesting support bit from the survey was the answer to, "I have used Go 
for..."  -  suggests that 1/3rd of the respondents have only 1 year 
experience or less with the language and a full half have less than 2 years 
experience. In my experience, when I started Go I was (and still am in some 
cases) using some Java paradigms in them that make sense to me which is 
great for transition but may not be great for the language long run

I am sure folks that have been around a while would agree that some of the 
reasons they are considering or actively changing languages tend to be due 
to bloat and unnecessary features that eventually weigh down productivity 
because there are 10 ways to skin the cat and everyone has a different 
opinion due to either how the rest of the code base does it or what is 
new.  

The large response to this thread suggests that potentially there may be a 
better feature out there that merits some attention and I would suggest it 
may be something that should come from the 2+ years experience crowd (if 
weighting of the results is possible) as those are likely the challenges 
that newbies like me will eventually encounter.  Weighing the survey 
results by experience may help Go stay ahead of the curve.  Just my .02

**  Side note:  I am a relative newcomer to Go (~8-9 months) so there is 
likely some bias there from my newness.  Add salt here

On Friday, June 28, 2019 at 7:44:01 PM UTC-5, Tyler Compton wrote:
>
> If anyone hasn't seen it, an issue with the "proposal" tag was created 
> earlier on the Go issue tracker titled "Proposal: leave "if err != nil" 
> alone?" (here ). This issue seems to 
> have resonated with a lot of people, which may be an important data point 
> when considering the try proposal , but 
> I was surprised to see how poorly the discussion has gone. There are quite 
> a few "me too" comments, a few image-only posts, some less than stellar 
> personal conduct, and overall not a lot of nuanced discussion. I feel that 
> perhaps these kinds of anti-proposals should be discouraged because they're 
> inherently reactionary, which seems to get the discussion off on the wrong 
> foot.
>
> That said, this anti-proposal attracted a whole new group of Go users that 
> I don't remember from the original try proposal discussion, which was 
> mostly dominated by ten or twenty participants. The discussion was better, 
> but the number of active users was much smaller. I wonder if there's a way 
> to better engage a larger portion of the Go user base while still 
> encouraging healthy, technical discussion.
>

-- 
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/1284af52-5fd6-4cd0-9bd3-cc69fd1c2fc7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] recover from a unexpected fault address

[Kurtis Rader]

Your program dereferenced a NULL pointer. This is most likely to be caused
by  C/C++ code you've linked with your Go code. You'll need to find out
what function is at address 0xd9c026. Try doing "ulimit -c unlimited" to
enable a core dump that you can then examine using a debugger like gdb.

On Mon, Jul 1, 2019 at 9:03 AM Mayank Jha  wrote:

> unexpected fault address 0x0
> fatal error: fault
> [signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0xd9c026]
>
> goroutine 11707890 [running]:
> runtime.throw(0x13c74b7, 0x5)
> /usr/local/go/src/runtime/panic.go:617 +0x72 fp=0xc0080ac5f0
> sp=0xc0080ac5c0 pc=0x42f5c2
> runtime.sigpanic()
> /usr/local/go/src/runtime/signal_unix.go:397 +0x401 fp=0xc0080ac620
> sp=0xc0080ac5f0 pc=0x444cf1
>
> Is there a way one can recover from such errors ? when does such error
> happen ? Any ideas ?
>
> --
> 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/7959bb0d-de87-49ae-828c-d3e02e062d7d%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD_zXBzYaNChLZKHOKyBZuofemutiFrDog%2BeWRsiTuxN8A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] recover from a unexpected fault address

[Mayank Jha]

unexpected fault address 0x0
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0xd9c026]

goroutine 11707890 [running]:
runtime.throw(0x13c74b7, 0x5)
/usr/local/go/src/runtime/panic.go:617 +0x72 fp=0xc0080ac5f0 
sp=0xc0080ac5c0 pc=0x42f5c2
runtime.sigpanic()
/usr/local/go/src/runtime/signal_unix.go:397 +0x401 fp=0xc0080ac620 
sp=0xc0080ac5f0 pc=0x444cf1

Is there a way one can recover from such errors ? when does such error 
happen ? Any ideas ?

-- 
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/7959bb0d-de87-49ae-828c-d3e02e062d7d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] .editorconfig for golang projects & github pr automated gofmt checks

[Sankar]

Hi

We use github for our sources. Developers are free to choose their IDEs and 
tools. Sometimes, people end up committing sources using spaces instead of 
tabs, etc. Not all developers do goimports/gofmt on save. So, we want to 
automate this process. However, instead of adding git pre-commit hooks, we 
want to have this done only when people raise a github PR. Have any of you 
done this in your project and shared your experience in a blog / writeup ? 
Please let us know. Googling would still be done for this, but wanted to 
ask in this list also.

Another somewhat related query is, we are also considering adding a 
.editorconfig for our Golang projects. Are there any standard .editorconfig 
settings for *.go that you use ?

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/e27fe1f7-402c-4a6a-8f65-a7536c052636%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Engels]

Ah, wasn't aware that was how finalizers were implemented in Go. I guess the 
reason I never need to know that, is because of the Go error handling - never 
needed to use them :)




-Original Message-
>From: Ian Lance Taylor 
>Sent: Jul 1, 2019 8:46 AM
>To: Robert Engels 
>Cc: Tyler Compton , Denis Cheremisov 
>, golang-nuts 
>Subject: Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal
>
>On Mon, Jul 1, 2019 at 6:20 AM Robert Engels  wrote:
>>
>> You’ve also mentioned stack allocation without destructors again. Isn’t the 
>> proper way to handle this with defer (which in an exception based system 
>> would still run) or finalizers? Java routinely allocates on the stack using 
>> escape analysis and it is not an problem there.
>
>Finalizers don't work on stack based objects, and in Go they are
>per-object, not per-type, so you have to remember to call
>runtime.SetFinalizer.
>
>Defer statements work, but you have to remember to write them even for
>a function that has no visible way to return.
>
>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/866930349.1876.1561989871232%40wamui-cheeto.atl.sa.earthlink.net.
For more options, visit https://groups.google.com/d/optout.

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

[Ian Lance Taylor]

On Mon, Jul 1, 2019 at 6:20 AM Robert Engels  wrote:
>
> You’ve also mentioned stack allocation without destructors again. Isn’t the 
> proper way to handle this with defer (which in an exception based system 
> would still run) or finalizers? Java routinely allocates on the stack using 
> escape analysis and it is not an problem there.

Finalizers don't work on stack based objects, and in Go they are
per-object, not per-type, so you have to remember to call
runtime.SetFinalizer.

Defer statements work, but you have to remember to write them even for
a function that has no visible way to return.

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

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

[Robert Engels]

I meant wrapping the lower level checked exceptions n a higher level exception. 
E.g. DataInputException that wraps date date format exceptions, missing entry 
exceptions etc. Easier for higher level functions to handle these than knowing 
all of the possible low level exceptions that could be thrown. 

I’ve found a good rule to be to limit the throws clause to at most 3 
exceptions, beyond that you need to handle/wrap in a higher level exception. 

I was only using fork/join as an example. In Go you still use this design - the 
response channel carries the request and response ( or error/exception ) - at 
least that is the way I would do it. 

You’ve also mentioned stack allocation without destructors again. Isn’t the 
proper way to handle this with defer (which in an exception based system would 
still run) or finalizers? Java routinely allocates on the stack using escape 
analysis and it is not an problem there.

> On Jul 1, 2019, at 2:11 AM, Ian Lance Taylor  wrote:
> 
>> On Sun, Jun 30, 2019 at 7:34 PM robert engels  wrote:
>> 
>> I’ve developed systems that wrap checked exceptions in unchecked ones, but 
>> in every case I can think of it was to “abort to the top” - returning 
>> control (or exiting) - it is a specialized case of the re-throw, but I would 
>> argue it is rarely used in anything other than framework type code, with 
>> applications code typically wrapping the specific exception in an 
>> “higher-level application checked exception”, that the upper layers handle 
>> (possibly inspecting the “cause” exception.
> 
> Sure, but as soon as you've wrapped a checked exception you've lost
> the advantage of checked exceptions, and gone back to having to worry
> about control flow at every function call.  Which, again, is a
> significant issue in a language like Go that uses stack allocation but
> does not have destructors.
> 
> 
>> As to not answering the question about transferring across Go routines, I 
>> apologize. It was not intentional - I read the statement a few times and 
>> didn’t quite get the concern - and meant to get back to it and forgot - but 
>> I read it again a few times and still don’t understand the problem.
>> 
>> What is particular about Go that makes this difficult? It is pretty common 
>> practice to pass exceptions across threads in Java and C++ - e.g. fork/join 
>> and the worker thread throws an exception - the exception is passed to the 
>> joining thread. Conceptually, it is as if the function was called serially 
>> and the exception thrown at the fork point. In these cases the exception is 
>> wrapped, but it has to be because of the strong type system. It is also 
>> pretty trivial to declare a wrapper function that declares the checked 
>> exceptions for clarity - this is done routinely in rpc using proxies.
> 
> Go doesn't have join.
> 
> Think about how you would write a basic Go construct like
> https://godoc.org/golang.org/x/sync/errgroup if errors are handled via
> exceptions.  I'm not saying you can't do it--of course you can do it.
> But it seems to me that it would require a bunch of awkward
> boilerplate that would be easy to get wrong.
> 
> 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/CAOyqgcVN6hEJKX0F9PikVvfo2w9fT9EUD7HqOzTCmN5ce5GNNA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/F776908C-EA7F-43C0-87DA-27CE8B46855E%40ix.netcom.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Engels]

Also, I already pointed out the problems of exceptions in functional designs 
(e.g. streams), luckily and thankfully for us Go doesn’t have that concern :)


> On Jul 1, 2019, at 1:46 AM, Sanjay  wrote:
> 
> 3 of the most well-known new languages in the past decade (Swift, Rust, and 
> Go, respectively) have all eschewed exceptions for control flow in favor of 
> some sigil in the source code to propagate errors explicitly. Swift uses 
> try-statements (along with a few other control flow constructs), Rust uses 
> the "?" operator (previously the try! macro), and Go uses "if err != nil".
> 
> C++, a language which does have exceptions, has significant fractions of its 
> user base which disable exception support entirely (20% according to a 
> survey) or partially (52%). Google, for instance, almost invariably compiles 
> with -fno-exceptions and uses macros to propagate errors explicitly (see 
> https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/stubs/status_macros.h#L49
>  to get a sense for how that works). Herb Sutter, one of the well-known 
> members of the C++ standards committee from Microsoft, has proposals out to 
> make propagating exceptions require a visible sigil in the source code (also 
> a "try" expression, FWIW): https://youtu.be/os7cqJ5qlzo?t=2939 (an 
> interesting talk overall, I've linked to the specific relevant time). His 
> actual proposal paper is also an interesting read: 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r3.pdf. In a 
> table with the following introduction "This section lays out what I believe 
> are ideal error handling characteristics. They are not unique to C++; I 
> believe they apply to most modern languages", he lists "Unhandled error 
> propagation is visible" as something not provided by C++ exceptions today.
> 
> It's possible that a decade from now, this will all have been a minor blip, 
> and you will eventually be proven right. But at the very least, this context 
> that should inform your priors.
> 
> Sanjay
> 
> PS - checked exceptions don't really have a great leg to stand on either 
> (e.g. consider their interaction with Java 8's streams: 
> https://www.oreilly.com/ideas/handling-checked-exceptions-in-java-streams, or 
> consider that both Scala and Kotlin don't implement support for them at all) 
> 
>> On Sunday, June 30, 2019 at 7:34:54 PM UTC-7, robert engels wrote:
>> I’ve developed systems that wrap checked exceptions in unchecked ones, but 
>> in every case I can think of it was to “abort to the top” - returning 
>> control (or exiting) - it is a specialized case of the re-throw, but I would 
>> argue it is rarely used in anything other than framework type code, with 
>> applications code typically wrapping the specific exception in an 
>> “higher-level application checked exception”, that the upper layers handle 
>> (possibly inspecting the “cause” exception. 
>> 
>> As to not answering the question about transferring across Go routines, I 
>> apologize. It was not intentional - I read the statement a few times and 
>> didn’t quite get the concern - and meant to get back to it and forgot - but 
>> I read it again a few times and still don’t understand the problem. 
>> 
>> What is particular about Go that makes this difficult? It is pretty common 
>> practice to pass exceptions across threads in Java and C++ - e.g. fork/join 
>> and the worker thread throws an exception - the exception is passed to the 
>> joining thread. Conceptually, it is as if the function was called serially 
>> and the exception thrown at the fork point. In these cases the exception is 
>> wrapped, but it has to be because of the strong type system. It is also 
>> pretty trivial to declare a wrapper function that declares the checked 
>> exceptions for clarity - this is done routinely in rpc using proxies. 
>> 
>> > On Jun 30, 2019, at 8:43 PM, Ian Lance Taylor  wrote: 
>> > 
>> > On Sun, Jun 30, 2019 at 5:23 PM robert engels  
>> > wrote: 
>> >> 
>> >> I am going to disagree here. I don’t think ‘checked exceptions’ exhibit 
>> >> this behavior. Addressing the points from the Joeal  article, 
>> > 
>> > Checked exceptions address some of the difficulties with exceptions. 
>> > However, they introduce new difficulties, and I do not believe they 
>> > work in large-scale programs.  In practice, checked exceptions 
>> > degenerate into unchecked exceptions.  Changing the set of exceptions 
>> > that a function throws forces all callers to adjust their set of 
>> > exceptions.  In practice this is so painful that programs catch 
>> > exceptions and turn into them into unchecked exceptions.  There are a 
>> > number of discussions on the Interwebs about the problems with checked 
>> > exceptions; here's one: https://www.artima.com/intv/handcuffs.html . 
>> > 
>> > I note that you didn't reply to my comment about passing errors across 
>> > goroutines. 
>> > 
>> > Ian 
>> > 
>> > -- 
>> > You received this message because you are 

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

[Robert Engels]

I agree that exceptions are definitely not in vogue, but there are a lot of 
things that are which I also don’t agree with - e.g. using Python to write 
anything more than page long scripts, writing major applications in JS, etc.

As someone that lived through the C errno days, and has spent a considerable 
portion of his career being brought in to fix things, I will firmly state that 
understanding and debugging a large system is far easier when exceptions are 
used correctly. 

Maybe a happier - at least for me :) - middle ground for Go would be to treat 
errors as a specialized type internally, and then to provide stack trace and 
chain information automatically (when using try) - carrying this information in 
a side channel that could be inspected/logged when required. 

I realize that this is completely anecdotal and most likely incorrect and 
really doesn’t prove anything :) - but I did a cursory review of major projects 
in Go and Java yesterday, and the defect rates on the Go side (reported issues 
filtered by bugs) seems far greater for similar code base sizes. I have a 
feeling this Go error handling has a small part in this - errors are harder to 
track down.

> On Jul 1, 2019, at 1:46 AM, Sanjay  wrote:
> 
> 3 of the most well-known new languages in the past decade (Swift, Rust, and 
> Go, respectively) have all eschewed exceptions for control flow in favor of 
> some sigil in the source code to propagate errors explicitly. Swift uses 
> try-statements (along with a few other control flow constructs), Rust uses 
> the "?" operator (previously the try! macro), and Go uses "if err != nil".
> 
> C++, a language which does have exceptions, has significant fractions of its 
> user base which disable exception support entirely (20% according to a 
> survey) or partially (52%). Google, for instance, almost invariably compiles 
> with -fno-exceptions and uses macros to propagate errors explicitly (see 
> https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/stubs/status_macros.h#L49
>  to get a sense for how that works). Herb Sutter, one of the well-known 
> members of the C++ standards committee from Microsoft, has proposals out to 
> make propagating exceptions require a visible sigil in the source code (also 
> a "try" expression, FWIW): https://youtu.be/os7cqJ5qlzo?t=2939 (an 
> interesting talk overall, I've linked to the specific relevant time). His 
> actual proposal paper is also an interesting read: 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r3.pdf. In a 
> table with the following introduction "This section lays out what I believe 
> are ideal error handling characteristics. They are not unique to C++; I 
> believe they apply to most modern languages", he lists "Unhandled error 
> propagation is visible" as something not provided by C++ exceptions today.
> 
> It's possible that a decade from now, this will all have been a minor blip, 
> and you will eventually be proven right. But at the very least, this context 
> that should inform your priors.
> 
> Sanjay
> 
> PS - checked exceptions don't really have a great leg to stand on either 
> (e.g. consider their interaction with Java 8's streams: 
> https://www.oreilly.com/ideas/handling-checked-exceptions-in-java-streams, or 
> consider that both Scala and Kotlin don't implement support for them at all) 
> 
>> On Sunday, June 30, 2019 at 7:34:54 PM UTC-7, robert engels wrote:
>> I’ve developed systems that wrap checked exceptions in unchecked ones, but 
>> in every case I can think of it was to “abort to the top” - returning 
>> control (or exiting) - it is a specialized case of the re-throw, but I would 
>> argue it is rarely used in anything other than framework type code, with 
>> applications code typically wrapping the specific exception in an 
>> “higher-level application checked exception”, that the upper layers handle 
>> (possibly inspecting the “cause” exception. 
>> 
>> As to not answering the question about transferring across Go routines, I 
>> apologize. It was not intentional - I read the statement a few times and 
>> didn’t quite get the concern - and meant to get back to it and forgot - but 
>> I read it again a few times and still don’t understand the problem. 
>> 
>> What is particular about Go that makes this difficult? It is pretty common 
>> practice to pass exceptions across threads in Java and C++ - e.g. fork/join 
>> and the worker thread throws an exception - the exception is passed to the 
>> joining thread. Conceptually, it is as if the function was called serially 
>> and the exception thrown at the fork point. In these cases the exception is 
>> wrapped, but it has to be because of the strong type system. It is also 
>> pretty trivial to declare a wrapper function that declares the checked 
>> exceptions for clarity - this is done routinely in rpc using proxies. 
>> 
>> > On Jun 30, 2019, at 8:43 PM, Ian Lance Taylor  wrote: 
>> > 
>> > On Sun, Jun 30, 2019 at 5:23 PM 

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

[Jesper Louis Andersen]

On Mon, Jul 1, 2019 at 3:43 AM Ian Lance Taylor  wrote:

>
> Checked exceptions address some of the difficulties with exceptions.
> However, they introduce new difficulties, and I do not believe they
> work in large-scale programs.


It is essentially a nominal effect system on exceptions. My bet is we are
better off it is was structural and thus automatically inferred by the
compiler. There is also the point that an exception must be a shared secret
between a raiser and a handler[0], which somewhat argues against the notion
of a checked exception in the first place.

[0]
https://existentialtype.wordpress.com/2012/12/03/exceptions-are-shared-secrets/

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

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

[Jesper Louis Andersen]

On Sun, Jun 30, 2019 at 7:05 PM Jan Mercl <0xj...@gmail.com> wrote:

> On Sun, Jun 30, 2019 at 3:19 PM Jesper Louis Andersen
>  wrote:
>
> > This is where the try-construct will definitely improve the ergonomics
> of the programming.
>
> With full respect to you opinion and/or personal preferences,
> "definitely improve" is just and only that. I _definitely_ don't share
> that opinion/personal preference.
>

I agree. That came out way too matter-of-factly.

I think it will improve ergonomics, because of the following analysis:

CON: New construct in the language means teaching and learning the language
takes more time.
CON: try(..) is a control operator. These are often harder to grasp and
rather subtle.
CON: It is sugar for a common pattern, which if written out could make code
easier to read.
PRO: It is sugar for a common pattern, which if not written out could make
code easier to read.
PRO: It will suggest a common pattern of error handling is easier to work
with in Go, thus make a stylistic choice.
PRO: It is, essentially, a typical Error monad. These are pretty common in
code and having special tooling for them tends to help.
PRO: Code is more often read then written. I think this optimizes for the
reader.
UNDECIDED: This is a pattern you also see in other languages.

My opinion, balancing those pros and cons, is that I think it ends up being
a net positive, but YMMV of course.



-- 
J.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAGrdgiVSF2GRX9YpebB1OuXAv%3DDfcSvvQXyCGYAPu%3D8we7C3sw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Henrik Johansson]

If it is as bad as "every sane Go shop" comes to this conclusion then I am
sure "try" will not be added...

On Mon, Jul 1, 2019 at 12:57 PM Wojciech S. Czarnecki 
wrote:

> On Mon, 1 Jul 2019 12:33:16 +0200
> Henrik Johansson  wrote:
>
> > That is one big strawman. I can live without "try" but
> > I think it would be a net gain for the language.
>
> I think it would be not. While anyone who consider 'try()' func being
> awkward
> and full of traps need not to use it in her code, everyone will have to
> cope
> with it while reading others code. Here lie dragons.
>
> 'Try()' might end as the first and topmost position on Go's "WE DON'T"
> blacklist. So it will waste Go team's time on implementing then
> maintaining,
> then every sane Go shop will forbid it.  (As it happened to C++ exceptions
> and many other C++ 'features' --  I'd seen 'we-dont' lists with over dozen
> positions).
>
> TC,
>
> --
> Wojciech S. Czarnecki
>  << ^oo^ >> OHIR-RIPE
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/20190701125733.4c41b9b2%40zuzia
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKOF695i%3Dnu8W2ujL6RQ_VNEQjHAjP9HAHarz5p4UnQJzNJYyg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Wojciech S. Czarnecki]

On Mon, 1 Jul 2019 12:33:16 +0200
Henrik Johansson  wrote:

> That is one big strawman. I can live without "try" but
> I think it would be a net gain for the language.

I think it would be not. While anyone who consider 'try()' func being awkward
and full of traps need not to use it in her code, everyone will have to cope
with it while reading others code. Here lie dragons.

'Try()' might end as the first and topmost position on Go's "WE DON'T"
blacklist. So it will waste Go team's time on implementing then maintaining,
then every sane Go shop will forbid it.  (As it happened to C++ exceptions
and many other C++ 'features' --  I'd seen 'we-dont' lists with over dozen
positions).

TC,

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

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

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

[Henrik Johansson]

That is one big strawman. I can live without "try" but I think it would be
a net gain for the language.
Sign of the times that any discussion becomes polarized I guess...

On Mon, Jul 1, 2019 at 12:18 PM Denis Cheremisov 
wrote:

> > I think many people like the proposal but are not vocal about it.
>
> Emoji count should reflect that "silent majority" better than comments. We
> have larger negative count on `try` and overwhelming 1293 vs 154 positive
> count on leaving it as is. People who care generally dislike poorly thought
> `try`, that's it.
>
> воскресенье, 30 июня 2019 г., 15:47:54 UTC+3 пользователь
> pierr...@gmail.com написал:
>>
>> Indeed.
>>
>> I think many people like the proposal but are not vocal about it. It is
>> not perfect but it *does *bring value to the table if you read the
>> proposal in its entirety and think about how you would use/could use it in
>> a real life scenario.
>>
>> I do *decorate *errors a lot, I do care about the *control flow* (I have
>> been along time user of *defer *for error handling and find it not
>> magical or ugly but fitting beautifully with the language), which are the
>> main topics people are complaining about... And I think it actually works
>> fine in those situations.
>>
>> In fact, the try() approach has started growing on me as I write code
>> now, I feel it would help in quite a few situations and simplify, not in a
>> drastic way, but subtle and valuable one.
>>
>> My 2c.
>>
>> Le samedi 29 juin 2019 21:31:19 UTC+2, Henrik Johansson a écrit :
>>
>>> I for one like the try proposal. It removes much of my gripes with the
>>> verbosity of error handling.
>>>
>>> I think that it will become more readable than explicit error handling
>>> quite fast. Note that it is still explicit, if you don't use the try
>>> notation the error can be handled as it is now or ignored as it sometimes
>>> is now.
>>>
>>> I have a feeling that there is a quite large "silent majority" that
>>> pretty much agrees with me.
>>>
>>> On Sat, Jun 29, 2019, 21:18 Denis Cheremisov 
>>> wrote:
>>>
 And prepare for wider audience in shitty “try” proposal after 1 July.

 --
 You received this message because you are subscribed to the Google
 Groups "golang-nuts" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to golan...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/golang-nuts/c99b3572-427c-4b7d-91ff-2fb4e4cb9177%40googlegroups.com
 .
 For more options, visit https://groups.google.com/d/optout.

>>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/49411503-e6f1-4be7-ae39-57b55e782779%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKOF697dWwSHcNi%3DS4ErwLVpEtV%3Dem8UExnQZiLbnpwOUDrkNQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Denis Cheremisov]

> I think many people like the proposal but are not vocal about it.

Emoji count should reflect that "silent majority" better than comments. We 
have larger negative count on `try` and overwhelming 1293 vs 154 positive 
count on leaving it as is. People who care generally dislike poorly thought 
`try`, that's it.

воскресенье, 30 июня 2019 г., 15:47:54 UTC+3 пользователь 
pierr...@gmail.com написал:
>
> Indeed.
>
> I think many people like the proposal but are not vocal about it. It is 
> not perfect but it *does *bring value to the table if you read the 
> proposal in its entirety and think about how you would use/could use it in 
> a real life scenario.
>
> I do *decorate *errors a lot, I do care about the *control flow* (I have 
> been along time user of *defer *for error handling and find it not 
> magical or ugly but fitting beautifully with the language), which are the 
> main topics people are complaining about... And I think it actually works 
> fine in those situations.
>
> In fact, the try() approach has started growing on me as I write code now, 
> I feel it would help in quite a few situations and simplify, not in a 
> drastic way, but subtle and valuable one.
>
> My 2c.
>
> Le samedi 29 juin 2019 21:31:19 UTC+2, Henrik Johansson a écrit :
>
>> I for one like the try proposal. It removes much of my gripes with the 
>> verbosity of error handling.
>>
>> I think that it will become more readable than explicit error handling 
>> quite fast. Note that it is still explicit, if you don't use the try 
>> notation the error can be handled as it is now or ignored as it sometimes 
>> is now.
>>
>> I have a feeling that there is a quite large "silent majority" that 
>> pretty much agrees with me.
>>
>> On Sat, Jun 29, 2019, 21:18 Denis Cheremisov  
>> wrote:
>>
>>> And prepare for wider audience in shitty “try” proposal after 1 July.
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to golan...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/c99b3572-427c-4b7d-91ff-2fb4e4cb9177%40googlegroups.com
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/49411503-e6f1-4be7-ae39-57b55e782779%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] YAEHI (Yet another error-handling idea)

[Liam]

I've noted in several places that a 'try' expression (via keyword, 
built-in, or symbol) is suitable only when the function is expected to 
always succeed, and so would panic on error.

Also the symbol, which I agree is preferable, works best this way 
will?(always?(work?())) vs will(always(work()?)?)?

On Saturday, June 29, 2019 at 4:05:44 PM UTC-7, Michael Jones wrote:
>
> My personal thought, though it may seem strange, is that the best argument 
> for it lies in the single word sentence at the bottom of your email. You 
> write "Thoughts?" -- and that is very expressive in English in just the way 
> that you mean above in your examples. I don't know enough other languages 
> to really know if the parallels are universal, but it's pretty clear to me 
> what it means why "file?.close()" and "os.Open(filename)?" are "punctuated" 
> as they are -- where the question is. I feel like you're asking this 
> compiler, "is there anything about this value that you need to tell me?" I 
> like that.
>
> The long (crazy long!) discussion of error handling has among its many 
> branches an analysis from the Go team about '?' and this kind of postfix 
> interrogation. I'm watching it all with a bit of wonder, but I wanted to 
> speak up and say how your human-language phrasing matches your idea of 
> computer-language phrasing. That seems a powerful kind of naturalness to 
> take advantage of in this issue and future ones.
>
> On Sat, Jun 29, 2019 at 2:56 PM Andrey Tcherepanov <
> xnow4f...@sneakemail.com > wrote:
>
>> Hello mighty fighters of errors!
>>
>> Here comes my half-thought idea of another way to express error handling:
>>
>> *Add a postfix '?' that checks value for **emptiness (nil, 0, "") **AND 
>> an error for nil. *
>>
>> (Denis have shred it to pieces already in 
>> https://github.com/golang/go/issues/32852. Thank you Denis.)
>>
>> I am not good with expressing my inner talk, so there are couple examples
>>
>> original , Go 1 function
>>
>> func stat(filename string) (os.FileInfo, error) {
>>
>> var info os.FileInfo
>> {
>> var a1 *os.File
>> if a1, err := os.Open(filename); err != nil || a1 == nil {
>> return _, err
>> }
>> var a2 os.FileInfo
>> if a2, err := a1.Stat(); err != nil || a2 == nil {
>> return _, err
>> }
>> info = a2
>> }
>> return info, nil
>> }
>>
>>
>> And with "?", trying to avoid original try() proposal handle leak
>>
>> // would return _, err, but since there is no err in signature, will return 
>> default value in case of error
>> // uses ? on func call that returns (value, error)
>> func stat2(filename string) (os.FileInfo) {
>>  file := os.Open(filename)? 
>>  defer file.Close()
>>  return file.Stat()?
>> }
>> // would return error too, uses ? as "not nil" on a variable too
>> func stat3(filename string) (_ os.FileInfo, err error) {
>>  var file *os.File
>>  defer file?.Close()
>>  file := os.Open(filename)?
>>  return file.Stat()
>> }
>>
>>
>> Thoughts?
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/b7520ffe-ec38-4157-8f95-92844dcb0d0f%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
>
> *Michael T. jonesmichae...@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/d02fd052-fd55-4ce0-83c1-65a84940006a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Ian Lance Taylor]

On Sun, Jun 30, 2019 at 7:34 PM robert engels  wrote:
>
> I’ve developed systems that wrap checked exceptions in unchecked ones, but in 
> every case I can think of it was to “abort to the top” - returning control 
> (or exiting) - it is a specialized case of the re-throw, but I would argue it 
> is rarely used in anything other than framework type code, with applications 
> code typically wrapping the specific exception in an “higher-level 
> application checked exception”, that the upper layers handle (possibly 
> inspecting the “cause” exception.

Sure, but as soon as you've wrapped a checked exception you've lost
the advantage of checked exceptions, and gone back to having to worry
about control flow at every function call.  Which, again, is a
significant issue in a language like Go that uses stack allocation but
does not have destructors.


> As to not answering the question about transferring across Go routines, I 
> apologize. It was not intentional - I read the statement a few times and 
> didn’t quite get the concern - and meant to get back to it and forgot - but I 
> read it again a few times and still don’t understand the problem.
>
> What is particular about Go that makes this difficult? It is pretty common 
> practice to pass exceptions across threads in Java and C++ - e.g. fork/join 
> and the worker thread throws an exception - the exception is passed to the 
> joining thread. Conceptually, it is as if the function was called serially 
> and the exception thrown at the fork point. In these cases the exception is 
> wrapped, but it has to be because of the strong type system. It is also 
> pretty trivial to declare a wrapper function that declares the checked 
> exceptions for clarity - this is done routinely in rpc using proxies.

Go doesn't have join.

Think about how you would write a basic Go construct like
https://godoc.org/golang.org/x/sync/errgroup if errors are handled via
exceptions.  I'm not saying you can't do it--of course you can do it.
But it seems to me that it would require a bunch of awkward
boilerplate that would be easy to get wrong.

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

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

[Sanjay]

3 of the most well-known new languages in the past decade (Swift, Rust, and 
Go, respectively) have all eschewed exceptions for control flow in favor of 
some sigil in the source code to propagate errors explicitly. Swift uses 
try-statements (along with a few other control flow constructs), Rust uses 
the "?" operator (previously the try! macro), and Go uses "if err != nil".

C++, a language which does have exceptions, has significant fractions of 
its user base which disable exception support entirely (20% according to a 
survey) or partially (52%). Google, for instance, almost invariably 
compiles with -fno-exceptions and uses macros to propagate errors 
explicitly (see 
https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/stubs/status_macros.h#L49
 to 
get a sense for how that works). Herb Sutter, one of the well-known members 
of the C++ standards committee from Microsoft, has proposals out to make 
propagating exceptions require a visible sigil in the source code (also a 
"try" expression, FWIW): https://youtu.be/os7cqJ5qlzo?t=2939 (an 
interesting talk overall, I've linked to the specific relevant time). His 
actual proposal paper is also an interesting read: 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r3.pdf. In a 
table with the following introduction "This section lays out what I believe 
are ideal error handling characteristics. They are not unique to C++; I 
believe they apply to most modern languages", he lists "Unhandled error 
propagation is visible" as something not provided by C++ exceptions today.

It's possible that a decade from now, this will all have been a minor blip, 
and you will eventually be proven right. But at the very least, this 
context that should inform your priors.

Sanjay

PS - checked exceptions don't really have a great leg to stand on either 
(e.g. consider their interaction with Java 8's streams: 
https://www.oreilly.com/ideas/handling-checked-exceptions-in-java-streams, 
or consider that both Scala and Kotlin don't implement support for them at 
all) 

On Sunday, June 30, 2019 at 7:34:54 PM UTC-7, robert engels wrote:
>
> I’ve developed systems that wrap checked exceptions in unchecked ones, but 
> in every case I can think of it was to “abort to the top” - returning 
> control (or exiting) - it is a specialized case of the re-throw, but I 
> would argue it is rarely used in anything other than framework type code, 
> with applications code typically wrapping the specific exception in an 
> “higher-level application checked exception”, that the upper layers handle 
> (possibly inspecting the “cause” exception. 
>
> As to not answering the question about transferring across Go routines, I 
> apologize. It was not intentional - I read the statement a few times and 
> didn’t quite get the concern - and meant to get back to it and forgot - but 
> I read it again a few times and still don’t understand the problem. 
>
> What is particular about Go that makes this difficult? It is pretty common 
> practice to pass exceptions across threads in Java and C++ - e.g. fork/join 
> and the worker thread throws an exception - the exception is passed to the 
> joining thread. Conceptually, it is as if the function was called serially 
> and the exception thrown at the fork point. In these cases the exception is 
> wrapped, but it has to be because of the strong type system. It is also 
> pretty trivial to declare a wrapper function that declares the checked 
> exceptions for clarity - this is done routinely in rpc using proxies. 
>
> > On Jun 30, 2019, at 8:43 PM, Ian Lance Taylor  > wrote: 
> > 
> > On Sun, Jun 30, 2019 at 5:23 PM robert engels  > wrote: 
> >> 
> >> I am going to disagree here. I don’t think ‘checked exceptions’ exhibit 
> this behavior. Addressing the points from the Joeal  article, 
> > 
> > Checked exceptions address some of the difficulties with exceptions. 
> > However, they introduce new difficulties, and I do not believe they 
> > work in large-scale programs.  In practice, checked exceptions 
> > degenerate into unchecked exceptions.  Changing the set of exceptions 
> > that a function throws forces all callers to adjust their set of 
> > exceptions.  In practice this is so painful that programs catch 
> > exceptions and turn into them into unchecked exceptions.  There are a 
> > number of discussions on the Interwebs about the problems with checked 
> > exceptions; here's one: https://www.artima.com/intv/handcuffs.html . 
> > 
> > I note that you didn't reply to my comment about passing errors across 
> > goroutines. 
> > 
> > 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 golan...@googlegroups.com . 
> > To view this discussion on the web visit 
>