RE: [Nolug] Go

Hi Joe.

Yes, Go has concurrency built it (and very nice!) but not parallelism (in
general). Sometimes you need one, sometimes the other, and sometimes both.

I haven't studied it in depth yet, but from what I gather you can tell the
compiler to spread the concurrent tasks across multi-cores but the current
state of the supervisor which does this isn't very good. I understand that it
is an area they are working on.

The overall architecture appeals to be very much, however. The concurrency is
extremely easy to implement (as little as adding "go" to a function
definition) and channels for message passing are a native type. The overhead
is very light, making them suitable for co-routine environments.

The ability to add parallelism to the mix by merely flipping a compiler switch
is certainly alluring!

I have played a bit with Perl's "ithreads" and they are quite nice. They are
more lightweight than most fork'ing implementations, so they can be used for
some concurrent solutions, and they multi-cores automatically.

Ultimately, I believe that as processor power increases horizontally (cores)
rather than vertically (speed) that the only way to make use of it is to run
parallel. For any given task, especially those which are centered on doing
one big thing, you can parallelize by hand. But if you simply want your
average day-to-day code to run faster without having to think about it and do
any extra work then I think that the programming language you use is key.
Otherwise the average programmer won't want to do the extra work it normally
takes now.

I should mention that I'm also looking at Haskell, partially for this reason,
too. Concurrency is easier to achieve in a functional language so there's
less effort on the part of the programmer. Haskell also claims to be very
expressive (fewer lines of code to get the job done) yet maintains excellent
run speed (very close to C). So it would seem to span the gap from a
speed-conscious system language to a low development time/cost scripting
language.

The major negative I have seen with Haskell is the learning curve. Functional
programming is a * VERY * different from imperative programming. It's a
totally different way of thinking about things. It's like of like saying that
driving and flying are two ways of getting from A to B, but they require very
different skillsets.

John

    John Souvestre - New Orleans LA - (504) 454-0899

From: owner-nolug@stoney.kellynet.org [mailto:owner-nolug@stoney.kellynet.org]
On Behalf Of joe jonass
Sent: Thu, December 12, 2013 3:37 pm
To: nolug@nolug.org
Subject: Re: [Nolug] Go

One of the blogs at the site says that it is geared for concurrent programming
and not parallelism (http://blog.golang.org/concurrency-is-not-parallelism).
It would be interesting to write a 'go' application that handles alot of
request and see if it distributes it across the cores.

On Thu, Dec 12, 2013 at 2:16 PM, John Souvestre <johns@sstar.com> wrote:

Hi Joe.

It's a relatively new language which some Google people designed as a
replacement for C and possibly other systems languages. Besides a simpler,
cleaner syntax it includes built-in primitives for concurrency.

At the moment my interest is mainly academic. I'm interested in languages
which make it easier to take advantage of multi-core processors.

John

    John Souvestre - New Orleans LA - (504) 454-0899
<tel:%28504%29%20454-0899>

From: owner-nolug@stoney.kellynet.org [mailto:owner-nolug@stoney.kellynet.org]
On Behalf Of joe jonass
Sent: Thu, December 12, 2013 2:11 pm
To: nolug@nolug.org
Subject: Re: [Nolug] Go

Never heard of it. Is there a particular problem or idea that you are trying
to match with software, paradigm, or are you looking at it from a academic
point of view?

On Wed, Dec 11, 2013 at 3:55 AM, John Souvestre <johns@sstar.com> wrote:

Hi.

I'm also looking at the programming language Go. I was wondering if anyone
here was using it?

John

    John Souvestre - New Orleans LA - (504) 454-0899
<tel:%28504%29%20454-0899>

___________________
Nolug mailing list
nolug@nolug.org