Re: [go-nuts] Channels may not be the best solution in Go

On Wed, Oct 2, 2019 at 11:07 PM Travis Keep wrote: > > I've been working on a math library github.com/keep94/gomath. This library > has functions for generating prime numbers, ugly numbers, harshad numbers, > happy numbers etc. Since there are infinitely many prime numbers, ugly > number,

[go-nuts] Channels may not be the best solution in Go

I've been working on a math library github.com/keep94/gomath. This library has functions for generating prime numbers, ugly numbers, harshad numbers, happy numbers etc. Since there are infinitely many prime numbers, ugly number, harshad numbers etc, these functions I wrote returned either a

[go-nuts] Re: causal profiling in Go

Hi, I just ran coz on a project of mine a few days ago. Building it properly was a little bit of trail and error to figure how out how get the build to play nice with the profiler but eventually I got it working. For builds, use go build -o -ldflags=-compressdwarf=false So that coz can

[go-nuts] Go Cloud Development Kit is looking for early adopters

"Go CDK provides commonly used, vendor-neutral generic APIs that you can deploy across cloud providers. The idea is to support hybrid cloud deployments while combining on-prem (local) and cloud tools." https://gocloud.dev/ -- You received this message because you are subscribed to the Google

[go-nuts] Go WASM question

I have sizable Go WASM application that creates map[string]interface{} and passes to JS or reads from JS library. Go maps do not have predefined key order. But JS has object property order predictable in JavaScript objects since ES2015. Problem: when JS objects are transferred from JS into Go

Re: [go-nuts] A confusion on the cgo document.

Got it. Thanks, Ian. On Mon, Sep 30, 2019 at 9:10 PM Ian Lance Taylor wrote: > On Mon, Sep 30, 2019 at 1:01 AM T L wrote: > > > > https://golang.org/cmd/cgo/#hdr-Passing_pointers > > > > When passing a pointer to a field in a struct, the Go memory in question > is the memory occupied by the

Re: [go-nuts] Re: Go policy does not fully support previous release

Hey, just because you asked for community-input multiple times (and I don't want to see claims again, that the Go team would ignore community input): I was aware of this policy and I agree with it. If nothing else, consider that as *users* of Go, we also benefit from this policy. Because at the

[go-nuts] Re: go binaries behaves differently on two identical linux servers

Presumably you are running the exact same binary (compiled Go program) on both server-1 and server-2. Hence the differences must be due to machine configuration. Something outside of your Go code. I suggest that you spin up a 3rd linode, clone it from master (or the working server) and

[go-nuts] Re: go binaries behaves differently on two identical linux servers

Presumably you are running the exact same binary (compiled Go program) on both server-1 and server-2. Hence the differences must be due to machine configuration. Something outside of your Go code. I suggest that you ppin up a 3rd linode, clone it from master (or the working server) and