One subtlety of having a built in concurrency model is that you avoid stripey programs[0]
If there is only one concurrency model, programs are built to match that concurrency model. If the model is in a library, you often have several competing concurrency models. This means that programs and libraries have "color" in the sense that some libraries only work with some specific other libraries. In practice, this divides a community into camps/clans/tribes where you can't readily share code between the camps. It leads to rewrites of perfectly fine code in order to make it fit into another model of concurrency. Contrast with a system such as Go: by picking a concurrency model up front, you can be reasonably sure the library you are looking at will work without too many assumptions about the underlying structure. Where such observations break apart is as soon as you look at Go's `context` package, or at Erlang's `OTP principles`. There, the underlying model is extended with certain rules. These rules make code able to coexist nicely in a system at the expense of giving the code color. If you look at the design of good concurrency models, they make it easy to move code around in a project without having to worry about which process/goroutine/context that code ran in. This is the reason why you have no goroutine identity. You could have made most of Go's concurrency into a library, but the model would be slightly more complicated. For 'select' to be a library, you need to have each case in the select be a first-class value you can pass around in the program and then you need a function which can combine these values into a single select case. A slightly weaker model is to have a select-this-event-ORELSE-select-that-event operator (see e.g., Haskell's STM and its `orElse` operator). However, by making it into a library, you possibly made the program less efficient than a built-in solution. With enough compiler machinery, you may be able to get back most of this efficiency, but it is not a priori clear it outweighs the cost. [0] This is a total aside: ever wondered why female cats have splotches of color males do not? Well, the color sits on the X chromosome of which the female cat has two. Early in the embryo, a deactivation process of one of the X's happens with about a 50/50 split. Cell growth then produces said cat, but depending on where the cell came from, fur has different colors. The same thing happens in human females, though there is no visible change due to this. And yes, it is completely irrelevant information, but I like to see programs as being stripey in this way, depending on what chromosomes it has. On Fri, Jan 20, 2017 at 6:17 AM Ian Lance Taylor <i...@golang.org> wrote: > On Thu, Jan 19, 2017 at 9:33 AM, John C. <jscrocket...@gmail.com> wrote: > > On several occasions the Go designers have alluded to the fact that the > > 'select' mechanism and the fact that it's built in to the language are > very > > important for concurrency (can't seem to find references). While I > > understand just fine how to use select/goroutines/channels, the > overarching > > importance of select as a built-in feature is escaping me. > > > > Can somebody help me see the big "why" picture better? > > Are you asking "why is select needed at all?" or are you asking "why > does select have to be built into the language?" > > Ian > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
