[go-nuts] [RFC] Yet another proposal for Go2 error handling

Mike Schinkel schrieb am Fr. 30. Juni 2023 um 07:04: *when err!=nil goto * What is the difference to `if err != nil { goto }` ? Go is awesome, because it does _not_ more and more syntax, especially with subtle nuances that one has to remember. > -- You received this message because you ar

Re: [go-nuts] [RFC] Yet another proposal for Go2 error handling

I think for what you want to do you don't need any language extension. You can implement all that within the current language. Look at this example: https://go.dev/play/p/aqjwzknrArH If you want to catch errors also in nested functions, you can also skip the ErrorChecker type and do it like this:

Re: [go-nuts] Re: Why is the reason that the flame graph in go pprof rotated 180 degrees?

a2800276 schrieb am Di. 13. Juni 2023 um 11:59: > 180 degrees in respect to what? ;) > In respect to a flame. ;-) -- 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

Re: [go-nuts] Hard-to-explain race detector report

Caleb Spare schrieb am Mi. 7. Juni 2023 um 19:22: > On Wed, Jun 7, 2023 at 2:33 AM Sven Anderson wrote: > > > > That’s not only a read/write race, it’s also a write/write race. Every > request to the server creates a new Go routine that might increment > newConns in pa

Re: [go-nuts] Hard-to-explain race detector report

That’s not only a read/write race, it’s also a write/write race. Every request to the server creates a new Go routine that might increment newConns in parallel, so it may get corrupted. Same for lines 39/40. You might claim, that for infrastructural reasons, there can be no concurrent requests to

Re: [go-nuts] 9 is prime if it's a hot day

a comment in the HTML source of > the document so that the answer is there for those who care to look? > > On Sun, 4 Jun 2023 at 08:01, Sven Anderson wrote: > > > > > Kamil Ziemian schrieb am Sa. 3. Juni 2023 um > 21:13: > > > Is this example found in the &quo

Re: [go-nuts] clarifying Go FAQ: Is Go an object-oriented language?

Ayan George schrieb am Di. 22. Nov. 2022 um 16:03: > > The Go FAQ begins the answer to the question, "Is Go an object-oriented > language," with, "yes and no." > […] > But I feel like programmers bringing their ideas from other less > ambiguously object oriented languages like Java and C++ often

Re: [go-nuts] Go routine context

Ian Lance Taylor schrieb am Sa. 1. Okt. 2022 um 17:12: > > Another example of goroutine-local storage that we currently support > is runtime/pprof.Do, which adds labels to the current goroutine. This > seems OK as the labels are readonly and are inherited by goroutines > started with a go statem

[go-nuts] gctx: a new package for a goroutine-local context

Dear all, TL;DR Set a goroutine context with gctx.Set(ctx) and retrieve it from anywhere in the same or a child goroutine with gctx.Get(): https://github.com/ansiwen/gctx This topic has been discussed many times already here and in issues. Go intentionally doesn't offer a way to identify the curr

Re: [go-nuts] Re: Should dev tools be tracked by go.mod?

Hi Sean, Thanks a lot for your answer! On Mon, Jan 24, 2022 at 9:01 PM Sean Liao wrote: > As a (hypothetical) consumer of your library, I would definitely > appreciate fewer dependencies, > mostly to reduce the chance of (or difficulty of resolving) conflicts with > any other dependencies I may

[go-nuts] Should dev tools be tracked by go.mod?

Hi everyone, In our project we are having a dispute on a very similar topic as the one raised by Rodolfo Carvalho recently , and input from this forum might help us to settle it. The

Re: [go-nuts] about -buildmode c-shared

On Mon, Dec 27, 2021 at 1:17 AM Ian Lance Taylor wrote: > Loading multiple Go DLLs built with -buildmode=c-shared ought to work > on ELF based systems like Linux. I don't know whether it will work on > Windows or macOS. I have a related question on that topic: How about support for a Go prog

[go-nuts] PtrGuard: a new package to break the Cgo pointer passing rules

Dear nuts, because we needed to use iovec APIs like the readv/writev system calls and wanted to avoid an additional memory copy, we needed to store Go pointers in C memory, or pass a Go pointer to memory that contains other Go pointers. In other words we needed to break the Cgo pointer passing rul