@bascule @celluloidrb Golang is built around channels of closures, not locked data structures.
-
-
-
@tqbf sure, and so is@celluloidrb. But neither Go nor Celluloid can formally ensure concurrent state mutations are impossible -
@bascule Doesn’t@celluloidrb involve me writing concurrent systems-level code in Ruby? Pass. -
.
@tqbf the correctness guarantees of@celluloidrb are largely the same. Go has better performance -
@bascule@celluloidrb I’ll take the safety of the type system in Golang over the safety of correctness of Celluloid+Ruby. -
@tqbf note that when it comes to guaranteeing the correctness of concurrent programs, Go is the same as@celluloidrb -
-
- 3 more replies
New conversation -
-
-
@bascule But it provides the actor-esque channel/goroutine based alternative, making it super-easy to avoid shared/mutable. -
@timbray in my experience as the maintainer of an actor framework that runs atop a shared mutable heap, this is not the case -
@bascule My first Go app had tons of concurrency and it was so easy/straightforward to use chan/go, no temptation to mutable state. -
@timbray you were still using shared mutable state -
@bascule I disagree. All the computation is in a goroutine which reads from a chan & writes to a chan. -
@timbray if you write a program that never mutates state that's fine ;) -
@bascule My point is, Go makes that easy AND all the samples/best-practices push you in that direction. -
@timbray it's "easy" to write a program that doesn't mutate state if you're trying. Ruby makes it easy too. It prefers copying over mutation - 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.