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.

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.

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 . (Only some though.)

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

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

Shared mutable state is a very efficient means of sharing data among multiple tasks. Contrast Erlang, which (AFAIK) has to make a copy of whatever data is being shared, and copying is a relatively expensive operation.

The downside of shared mutable state is that it pushes the burden of correctness out of the language and onto the programmer. With Erlang's approach, data races are impossible. With Go's approach, you have to apply an optional static analysis (the built-in data race detector) to give you any assurance of correctness (and that's only a heuristic, not a guarantee of correctness).

Go's approach is that you basically have to trust the programmer at some point and as far as reasoning about the logic goes you should consider any mutable state sent over a channel to be owned by the receiving goroutine.

Modifying it by the sender after channel transmission is considered very bad form though the compiler allows it and you can safely get away with it as long as you properly mutex lock your accesses.

I have the same feeling. Have you checked Rust? It is a different approach where ownership and mutability are strictly controlled via the type system.

Yep, I'm very excited about Rust. I think per task/process heaps is really key to getting concurrency and reliability done right. Also the type system and aim for zero cost abstractions seems great. That said, it is still pretty early stage so I'm holding off for the 1.0 release.

These posts are great, pheelicks, keep it up! Your previous post inspired me to make this: 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.

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.

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.

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.

Was it this submission? Same blog, a few weeks back. https://news.ycombinator.com/item?id=6542082

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

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...

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.

The Go runtime has a built-in scheduler which historically would be called into action for possible preemption whenever an OS system call is made or could be invoked manually in Go code via runtime.Gosched(). Go 1.2 added a change allowing the scheduler to possibly be kicked off during any Go language function call which reduces the likelihood of being locked in a tight loop that never makes a system call.

There are obviously still cases where you can trap yourself into a deadlock by tight looping in code that makes no function calls at all, but it is pretty easy to detect this and adjust for it.

Is it really any more magical than how OS threads get mapped to CPU cores?