Roger Critchlow wrote:
I found it even more apparent on this pass through that the language
is very well built for the kind of parallel programming that I've
become comfortable with in erlang. That is, go makes it very easy to
spin off a new thread/process/goroutine and establish communications
using channels. This is a matter of being able to easily instantiate
the appropriate graph of communicating sequential processes to a
computational task, receive the result of the computation when it
finishes or fails, and know that all the cruft got cleaned up. So if
your computation can be pipelined or fanned out onto multiple cores,
I can see that goroutines and channels are appealing programming
abstractions, but have a hard time believing they could scale. Seems
like the more goroutines you have the more CPU cycles that will be
absorbed in switching amongst them. I could see how distributed
Erlang would scale with lots of high latency _network_ messages in
flight -- the amount of time for switching would be small compared to
the latency of the message. That wouldn't seem to be the case with
Google Go, which would all be in core.
Marcus
============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
lectures, archives, unsubscribe, maps at http://www.friam.org
