
Intro to images in Go – concurrency - pheelicks
http://www.pheelicks.com/2013/10/intro-to-images-in-go-concurrency/
======
chrisavl
Nice visuals! But this highlights one thing about Go that irks me coming from
Erlang: sending mutable state over channels. Here the power of a node is
modified in another nodes goroutine, which makes things much trickier to
reason about. A better approach, IMO, would be to decrement the power before a
node sends itself over a channel.

~~~
pheelicks
Good point - I agree that it would be cleaner that way. Do you know if the
sending of mutable state over channels was a specific design decision in Go?
I'd be interested to know if there was a difference in philosophy between it
and Erlang here.

~~~
jerf
In general, Go has a sort of "good enough" or very pragmatic philosophy. It
offloads strict enforcement of non-sharing between goroutines to the user and
community best practices, but provides no compiler enforcement, which would be
very difficult due to the fact that the entire rest of the language is
mutable.

Erlang's design was driven by much stronger philosophical principles and an
unusual initial use case (phone switch programming).

I'm not saying either is necessarily better and worse. The end result is that
Go is a much more mainstream language with a lot of refinements, and Erlang is
the sort of bizarre-but-oddly-useful language you get when a strong philosophy
is carried through to its full logical conclusion. (See also Haskell.)

If you _really, really_ care about compiler-enforced safety, Go is not a good
choice. Not only will it let you shoot yourself in the foot, it won't really
do _that_ much to stop you. (Indeed, this presentation is almost terrifying
from the perspective of an Erlang programmer, so many ways to screw up with
the compiler only noticing a handful of them: [1] slides: [2]) However, if
you're sort of interested in the sorts of things that can give you but aren't
ready to put on the hair-shirt (a metaphor from the Haskell community), Go has
some ways of putting your toes into the water and getting some of the
practical benefits without a ton of the theory, for instance:
[http://www.jerf.org/iri/post/2923](http://www.jerf.org/iri/post/2923) . (Only
some though.)

[1]:
[http://www.youtube.com/watch?v=QDDwwePbDtw](http://www.youtube.com/watch?v=QDDwwePbDtw)

[2]:
[http://talks.golang.org/2013/advconc.slide](http://talks.golang.org/2013/advconc.slide)

------
nemo1618
These posts are great, pheelicks, keep it up! Your previous post inspired me
to make this:
[http://github.com/lukechampine/algo](http://github.com/lukechampine/algo)

My 3D renderer still suffers from faulty compositing (polygons are rendered in
arbitrary order, instead of according to their respective depths) but I like
being able to see an animated result instead of just a static image.

------
stevenbedrick
This is probably a stupid question, but is the Canvas's DrawLine function
thread-safe? It looks like multiple Nodes could be drawing to the same canvas
at the same time, and I don't see any locks/mutexes/whatevers wrapping that
call.

Obviously it can't be _too_ much of a big deal, since the (very nifty) example
works just fine, but I'm curious about what's going on here.

~~~
icebraining
I'm a noob at concurrent programming, but from what I can tell, the only
concurrent mutation is when setting the pixels, in image.go:

    
    
        94		p.Pix[i+0] = c1.R
        95		p.Pix[i+1] = c1.G
        96		p.Pix[i+2] = c1.B
        97		p.Pix[i+3] = c1.A
    

IIRC, copying a single byte is safe, so what could happen is that you could
end up with weird pixels, if two nodes were setting the same pixel at the same
time.

------
kawsper
There was another post here on HN about Go and working with images, the author
was very impressed with the standard library because it could do a lot with
images.

Unfortunately, I have tried to search for the article but I can't find it.

~~~
mikeevans
Was it this submission? Same blog, a few weeks back.
[https://news.ycombinator.com/item?id=6542082](https://news.ycombinator.com/item?id=6542082)

~~~
kawsper
Yes! Thats it! Thanks, this is now bookmarked.

------
topbanana
How do goroutines map to native OS threads? How do they get scheduled? It all
seems a bit magical to me - which is great when things work as expected...

~~~
lucian1900
They get multiplexed across a few OS threads.

There is a scheduler which will leave goroutines that do a native (potentially
blocking) call in their own thread.

