5 ms·

Please read http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... It illust

by jtolds 8y ago

Please read http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... It illustrates decisively that a language that doesn't hide async behavior balkanizes libraries into (at least) two camps for everyone's detriment. Fixing this and doing it correctly requires language support, yes (the language's mutexes must work right in the appropriate contexts) but it is much better for the ecosystem to hide the details of async. Making the programmer deal with async nature (even with await, yield, etc) adds additional unnecessary details for the programmer to worry about and makes the program harder to reason about. As for where the industry is headed, Go shows what it's like getting this right.

dom96 8y ago
It seems to me that a simple solution to this is to default to using async for everything. That way there is no "colours", everything is a single colour (async) and everybody is happy. Can you see a problem with this approach?
- jtolds 8y ago
  Nope! That's what Go does under the hood... and then eliminates keywords like await/yield and promises, because they're always implicitly there.
  - jtolds 8y ago
    On Linux, nonblocking IO has not always been great, so under the covers Go often translates calls to actually schedule blocking work on a threadpool somewhere, but from the perspective of the programmer, everything is implicitly using await/yield and promises.
zzzcpan 8y ago
What color is your function is one the most inadequate articles on concurrency ever written. Even managed to claim shared memory multithreading as superior to all other concurrency models. It's sad that it's popular, shows how little people understand about the subject.
- jtolds 8y ago
  The article isn't about concurrency in general though. It's explicitly about the question of how coroutines are called and implemented. The article is specifically about one facet of concurrent programming that arises when you use shared memory multitasking. I would imagine articles that focus on a small subpiece of concurrency are inadequate articles about concurrency in general, yes.
  - zzzcpan 8y ago
    But it is. It tries to argue that other concurrency models are bad, because they do not look like shared memory multithreading. Even though other concurrency models actually aim for something different than shared memory multithreading to at least get away from its flaws.
    - jtolds 8y ago
      Where does it talk about other concurrency models at all? I just reread it to make sure I wasn't crazy.
      - zzzcpan 8y ago
        Pretty much throughout the whole article. Callbacks, promises/futures, async/await for example all assume different concurrency model from shared memory multithreading and hence are programmed differently.
        deleted 8y ago
        [deleted]
        jtolds 8y ago
        The article is explicitly saying that green threads are better than callbacks, promises/futures, and async/await, yes. It is definitely making a comparison between those two styles of implementations, and it is saying that (what you call) shared memory multithreading is better than callbacks. I want to point out though that the article is not claiming OS 1:1 threading is better than async/await/callbacks. OS-level 1:1 threading is too heavy, and it's obvious that many programmers reach for callbacks to handle high concurrency evented I/O. The article is claiming that languages that allow a blocking style of programming via green threads (to still get the same high concurrency) allow a more natural way to program. Your point was the article was one of "the most inadequate articles on concurrency ever written." I agree. It wasn't trying to be a complete article on concurrency. It says nothing about the actor model. Then you said it "Even managed to claim shared memory multithreading as superior to all other concurrency models." The article doesn't talk about all other concurrency models. It only talks about the programming styles that "shared memory multithreading" is better than.
dnomad 8y ago
> It illustrates decisively that a language that doesn't hide async behavior balkanizes libraries into (at least) two camps for everyone's detriment. That article simply begs the question. Or rather, I think the author has missed the point. Advocates of Futures-based APIs for example don't regard the balkanization as a bad thing. That's the point -- asynchronous functions really are different, they really do accept and return different types of values in the form of callbacks and futures. Threading and shared memory don't solve anything, btw. These are implementation details. This is not about implementation so much as it's about expressing contracts between modules. Go channels are, frankly, rather useless but still, to my point, they don't try to hide asynchronous behavior. Go could've gone whole hog and provided yield and subsumption but I think they wisely realized that concurrency at scale requires shared nothing message passing. Or rather the essential insight of CSP (and Actors, and PPP and so many other models) is that reifying events and the flow of events is a good thing. (Though I've heard it proposed that this is just because the limited human mind is "event oriented". Super intelligent martians and AIs would use Dataflow[1] languages to talk about the illusion of time. They might see the world as a giant spreadsheet.) > Making the programmer deal with async nature (even with await, yield, etc) adds additional unnecessary details for the programmer to worry about and makes the program harder to reason about. Again, I think it's kind of wacky to think that the async nature is "unnecessary" or accidental for the programmer. The solution the programmer is trying to model is asynchronous. The whole point is to allow the end User to do stuff while you talk to the database or process multiple trades at the same time. You can't wish this asynchronous nature of the problem away because its asynchronous nature, rather than being an unnecessary detail, is the problem. A lot of very smart people have spent a lot of time trying to "solve" concurrency by making it invisible. All failed. The issues around concurrency are a problem that must be addressed head on. Types are the abstraction that let us be very precise for describing how a system can change. Using the type system to bring the problems of concurrency to the forefront so that they can reasoned about and enforced by the compiler is absolutely absolutely a good thing. People don't like this though because concurrent APIs are "viral". One asynchronous function now requires all callers to either block or become asynchronous themselves. But this was always the case anyways. As Morpheus would say, "How would this be different from any other day?" [1] https://en.wikipedia.org/wiki/Dataflow_programming https://en.wikipedia.org/wiki/Dataflow_programming

by jtolds 8y ago

dom96 8y ago

It seems to me that a simple solution to this is to default to using async for everything. That way there is no "colours", everything is a single colour (async) and everybody is happy. Can you see a problem with this approach?

jtolds 8y ago
Nope! That's what Go does under the hood... and then eliminates keywords like await/yield and promises, because they're always implicitly there.
- jtolds 8y ago
  On Linux, nonblocking IO has not always been great, so under the covers Go often translates calls to actually schedule blocking work on a threadpool somewhere, but from the perspective of the programmer, everything is implicitly using await/yield and promises.

zzzcpan 8y ago

What color is your function is one the most inadequate articles on concurrency ever written. Even managed to claim shared memory multithreading as superior to all other concurrency models. It's sad that it's popular, shows how little people understand about the subject.

jtolds 8y ago
The article isn't about concurrency in general though. It's explicitly about the question of how coroutines are called and implemented. The article is specifically about one facet of concurrent programming that arises when you use shared memory multitasking. I would imagine articles that focus on a small subpiece of concurrency are inadequate articles about concurrency in general, yes.
- zzzcpan 8y ago
  But it is. It tries to argue that other concurrency models are bad, because they do not look like shared memory multithreading. Even though other concurrency models actually aim for something different than shared memory multithreading to at least get away from its flaws.
  - jtolds 8y ago
    Where does it talk about other concurrency models at all? I just reread it to make sure I wasn't crazy.
    - zzzcpan 8y ago
      Pretty much throughout the whole article. Callbacks, promises/futures, async/await for example all assume different concurrency model from shared memory multithreading and hence are programmed differently.
      - deleted 8y ago
        [deleted]
      - jtolds 8y ago
        The article is explicitly saying that green threads are better than callbacks, promises/futures, and async/await, yes. It is definitely making a comparison between those two styles of implementations, and it is saying that (what you call) shared memory multithreading is better than callbacks. I want to point out though that the article is not claiming OS 1:1 threading is better than async/await/callbacks. OS-level 1:1 threading is too heavy, and it's obvious that many programmers reach for callbacks to handle high concurrency evented I/O. The article is claiming that languages that allow a blocking style of programming via green threads (to still get the same high concurrency) allow a more natural way to program. Your point was the article was one of "the most inadequate articles on concurrency ever written." I agree. It wasn't trying to be a complete article on concurrency. It says nothing about the actor model. Then you said it "Even managed to claim shared memory multithreading as superior to all other concurrency models." The article doesn't talk about all other concurrency models. It only talks about the programming styles that "shared memory multithreading" is better than.

dnomad 8y ago

> It illustrates decisively that a language that doesn't hide async behavior balkanizes libraries into (at least) two camps for everyone's detriment. That article simply begs the question. Or rather, I think the author has missed the point. Advocates of Futures-based APIs for example don't regard the balkanization as a bad thing. That's the point -- asynchronous functions really are different, they really do accept and return different types of values in the form of callbacks and futures. Threading and shared memory don't solve anything, btw. These are implementation details. This is not about implementation so much as it's about expressing contracts between modules. Go channels are, frankly, rather useless but still, to my point, they don't try to hide asynchronous behavior. Go could've gone whole hog and provided yield and subsumption but I think they wisely realized that concurrency at scale requires shared nothing message passing. Or rather the essential insight of CSP (and Actors, and PPP and so many other models) is that reifying events and the flow of events is a good thing. (Though I've heard it proposed that this is just because the limited human mind is "event oriented". Super intelligent martians and AIs would use Dataflow[1] languages to talk about the illusion of time. They might see the world as a giant spreadsheet.) > Making the programmer deal with async nature (even with await, yield, etc) adds additional unnecessary details for the programmer to worry about and makes the program harder to reason about. Again, I think it's kind of wacky to think that the async nature is "unnecessary" or accidental for the programmer. The solution the programmer is trying to model is asynchronous. The whole point is to allow the end User to do stuff while you talk to the database or process multiple trades at the same time. You can't wish this asynchronous nature of the problem away because its asynchronous nature, rather than being an unnecessary detail, is the problem. A lot of very smart people have spent a lot of time trying to "solve" concurrency by making it invisible. All failed. The issues around concurrency are a problem that must be addressed head on. Types are the abstraction that let us be very precise for describing how a system can change. Using the type system to bring the problems of concurrency to the forefront so that they can reasoned about and enforced by the compiler is absolutely absolutely a good thing. People don't like this though because concurrent APIs are "viral". One asynchronous function now requires all callers to either block or become asynchronous themselves. But this was always the case anyways. As Morpheus would say, "How would this be different from any other day?" [1] https://en.wikipedia.org/wiki/Dataflow_programming https://en.wikipedia.org/wiki/Dataflow_programming