Intro to images in Go – concurrency
pheelicks.com
Intro to images in Go – concurrency
1–10 of 18 posts
Re: Intro to images in Go – concurrency
#2Nice 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.
Re: Intro to images in Go – concurrency
#3Nice 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.
Re: Intro to images in Go – concurrency
#4How 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...
Re: Intro to images in Go – concurrency
#5How 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.
Re: Intro to images in Go – concurrency
#6Nice 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.
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).
Re: Intro to images in Go – concurrency
#7Nice 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.)
Re: Intro to images in Go – concurrency
#8There 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.
Re: Intro to images in Go – concurrency
#9There 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
Re: Intro to images in Go – concurrency
#10Nice 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.
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.