Re: [go-nuts] Re: Why, oh why, do people do this? Things that annoy me in Go code.

Idiomatic naming in Go is one of the hardest things to communicate. Everyone seems to bring the idioms from previous languages. Dave Cheney writes about "Lengthy bureaucratic names carry a low amount of signal compared to their weight on the page". Identifiers are not sentences or stand alone

Re: [go-nuts] Generic pointer field comparable with single type parameter possible?

On Wed, Feb 2, 2022 at 5:29 AM Ed Pelc wrote: > I was able to get this to work but I'm curious if it could be simplified > at all as it seems complicated to require two type parameters for this. I > figured this out after trying to follow the `pointer method` >

[go-nuts] Re: Generic pointer field comparable with single type parameter possible?

**please use this as single type parameter version instead: https://gotipplay.golang.org/p/ZrOqCj1R_va On Tuesday, February 1, 2022 at 11:29:05 PM UTC-5 Ed Pelc wrote: > Hello, > > I'm trying out the go1.18beta2 by attempting to move from codegen based > generics using a custom tool to 1.18's

[go-nuts] Generic pointer field comparable with single type parameter possible?

Hello, I'm trying out the go1.18beta2 by attempting to move from codegen based generics using a custom tool to 1.18's type parameters. I looked extensively for examples and others trying to do something similar but found little. I figured out a working way to do this but it seems extensive.

[go-nuts] Re: Intentionally omitting requires in go.mod - alternative to multi-module repository?

On Monday, January 31, 2022 at 1:22:09 AM UTC-5 leig...@gmail.com wrote: > I'm a user of the sentry-go SDK who has been impacted by the large number > of dependencies in the past. > > >Independently, if your users have automated tools that are issuing > false-positive CVE warnings based on the

Re: [go-nuts] GOAMD64 build tags?

On Tue, Feb 1, 2022 at 4:34 AM Klaus Post wrote: > > I looked through the source to see if `GOAMD64` version results in build tags > being set, but I was unsure if that is the case. > > It would be really helpful for assembly code that can be assumed to work > without cpuid checks, avoiding a

Re: [go-nuts] Issues when using time.Ticker microsecond duration

In my tests 2000 events per second appear to be fine, but there is an issue a magnitude larger with 20 000 events per second. On Tuesday, February 1, 2022 at 10:50:29 AM UTC+1 Ian Davis wrote: > On Mon, 31 Jan 2022, at 8:33 PM, Uli Kunitz wrote: > > Please have a look at golang.org/x/time/rate

[go-nuts] GOAMD64 build tags?

Hi! I looked through the source to see if `GOAMD64` version results in build tags being set, but I was unsure if that is the case. It would be really helpful for assembly code that can be assumed to work without cpuid checks, avoiding a bit of branching. For example adding

Re: [go-nuts] Issues when using time.Ticker microsecond duration

On Mon, 31 Jan 2022, at 8:33 PM, Uli Kunitz wrote: > Please have a look at golang.org/x/time/rate > . This package should solve your > problem. > > Here is an example with 10 events per second. > > func main() { >