>
>
> Not all programs benefit from concurrency. Writing concurrent code for
> essentially sequential programs will not benefit from multiple cores,
> like generating prime numbers. Do not forget that concurrency includes
> overhead for context switch and memory barriers. Using channels in a
> sequ
JuciÊ, I'm not going to endorse or dispute you assertions in the general
case.
But, I do want to point out that the OP started with "I've been working on
a math library". It then provides a link to the library on github. It may
be a matter of personal choice and style when writing an applicati
Travis, glad to hear that you are exploring Harshad Numbers. It is an area
where I have done more than a decade of work and I did not know that anyone
else even cared about them. If you ever want to know how many thousand
digit (or whatever) base 10 (or whatever) numbers have the Harshad
property,
On Thu, Oct 3, 2019 at 11:59 AM JuciÊ Andrade wrote:
>
> Burak, feel free to correct me if I am wrong, but now I think I understood
> the heart of the matter:
>
> Your approach to software development is different from mine. Nothing wrong
> with that.
>
> . you normally write sequential code, an
- think map/reduce at scale. Often the complexity of concurrency within a process is not needed (or is completely hidden away).-Original Message-
From: JuciÊ Andrade
Sent: Oct 3, 2019 12:58 PM
To: golang-nuts
Subject: Re: [go-nuts] Channels may not be the best solution in Go
Burak, feel
Burak, feel free to correct me if I am wrong, but now I think I understood
the heart of the matter:
Your approach to software development is different from mine. Nothing wrong
with that.
. you normally write sequential code, and uses concurrent code where it
fits best. That is fine.
. I use to
On Thu, Oct 3, 2019 at 8:40 AM JuciÊ Andrade wrote:
>
> On Thursday, October 3, 2019 at 10:47:27 AM UTC-3, burak serdar wrote:
>>
>> On Thu, Oct 3, 2019 at 6:18 AM JuciÊ Andrade wrote:
>> > I use channels exactly that way and they work pretty well.
>>
>> Then you're paying some penalty for synchr
On Thursday, October 3, 2019 at 10:47:27 AM UTC-3, burak serdar wrote:
>
> On Thu, Oct 3, 2019 at 6:18 AM JuciÊ Andrade > wrote:
> > I use channels exactly that way and they work pretty well.
>
> Then you're paying some penalty for synchronization where the same
> thing can be achieved without
On Thu, Oct 3, 2019 at 6:18 AM JuciÊ Andrade wrote:
>
> On Thursday, October 3, 2019 at 2:24:20 AM UTC-3, burak serdar wrote:
>>
>> It can be argued that you were misusing channels. Channels are
>> synchronization mechanisms between goroutines. They are not generic
>> data pipes.
>
>
> I use chann
On Thursday, October 3, 2019 at 2:24:20 AM UTC-3, burak serdar wrote:
>
> It can be argued that you were misusing channels. Channels are
> synchronization mechanisms between goroutines. They are not generic
> data pipes.
>
I use channels exactly that way and they work pretty well.
--
You rece
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, har
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 ch
12 matches
Mail list logo
