No subject

share memory by communicating."  This does not imply Go can't share memory.

At:
http://golang.org/doc/effective_go.html#concurrency

They say "A goroutine has a simple model: it is a function executing in
parallel with other goroutines in the same address space."

So for instance my code which generates a NxN array of mandelbrot escape
values assigns the work via the above channel to a go routine, but the
go routines all write directly to an array that's in the same address
space.  Go has pointers, but not pointer arithmetic (unless I'm
misremembering my languages).

> Or have a misread the Go Web page?

I think so.

> What is your opinion of the Cilk language?

Not heard of it, sounds interesting though.  Assuming you mean Cilk-5
which is a C extension.  I've written some pthreads based code and I'll
have to look closer to compare.  My main concern is that a design might
be limiting so that it only works well with a subset of parallel
problems.  The 2009 paper on reducer hyperobjects is now on my reading
list, er it would be if I could find it.  Alas, one likely place
http://www.cs.jhu.edu/ is down.  Got a link?  Frustratingly they don't
seem to provide a title or a link and the ACM has a rather poor
reputation for sharing.  Ah, I'm guessing this is the paper:
  http://www.fftw.org/~athena/papers/hyper.pdf