4 ms·

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

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 13y ago
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.
- kibwen 13y ago
  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).
- jerf 13y ago
  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
- georgemcbay 13y ago
  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.
drewhk 13y ago
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.
- chrisavl 13y ago
  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.

pheelicks 13y ago

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.

kibwen 13y ago
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).
jerf 13y ago
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
georgemcbay 13y ago
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.

drewhk 13y ago

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.

chrisavl 13y ago
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.