5 ms·

I'm a little sad the async/await model is winning over. I really prefer Go's CSP. It can do everything the async/await model can, plus "streaming" API's. I dig

I'm a little sad the async/await model is winning over. I really prefer Go's CSP. It can do everything the async/await model can, plus "streaming" API's. I dig (sorta) C#'s async/await, but I still don't see why it's "winning" over other, better models...

idibidiart 11y ago
CSP can be implemented on top of async/await, which itself is implemented on top of promise and generators. What does streaming APIs have to do with CSP per se?
findjashua 11y ago
for consuming 'streaming APIs', why not just use observables (rx.js etc)?
- bklimt 11y ago
  Observables are great, and are indeed the stream equivalent to Tasks. But the await/async keyword compilation doesn't support them. I think that's the parent post's point.
  - josteink 11y ago
    I've seen stream-like constructs done with c# async and await and to me it even looked elegant. Could you expand on in what way you think async and await is insufficient with regards to streams? I'm genuinely curious.
    - colin_jack 11y ago
      Would you have a link to an example of a streaming API done elegantly with async? I'm interested to see what it looks like.
      - josteink 11y ago
        It was during a presentation on the NDC developer conference a few years back, when the feature was new to C#. I remember thinking it was one of the best presentations that year, but right now I don't remember what year it was, and I can't find any past agendas to search either. NDC posts their videos online after each conference, and I did a quick skim. I think it may be this session here, but I haven't double-checked: https://vimeo.com/43808831 https://vimeo.com/43808831 Edit: It was a 2-part session and it may also have been in second half. Link here: https://vimeo.com/43808833 https://vimeo.com/43808833
        colin_jack 11y ago
        Much appreciated ta, will give it a look.
bklimt 11y ago
The one advantage of C#'s async/await over Go's CSP is that by exposing the underlying Tasks, you can take more control over how the continuations get executed. The result of this is that it's easy to have async code that all runs on the same thread (usually the UI thread) even while it calls a function makes a network request that gets scheduled to a background thread. Go's model doesn't give you as much control over which thread a particular operation gets assigned to. It's not theoretically impossible, I suppose, but it's hard to imagine what a simple API for it would look like. But yes, if this particular problem were solved in an elegant way, I would also prefer the CSP model. It makes it so you don't have to worry about which operations are async or not.
- _wmd 11y ago
  This was one of my main worries about Go when I evaluated it back in 2010. Most green threads implementations have an explicit determinism model, and it's typically straightforward to reason about and depend on execution order and suchlike, much as you can with plain asynchronous code, but with Go there didn't appear to be any guarantee when or how your code ran. In any case I suppose many styles of Go program will exhibit accidental determinism, but it still seems too difficult to depend on as randomness can be introduced simply by invoking the wrong function, or by using a different runtime version, which to me feels comparable to the hazards of raw multithreading.
- novaleaf 11y ago
  A huge problem with C#'s Async feature that I hope gets resolved (and, obviously that this failure pattern is not ported to Javascript): Explicitly blocking during a function that uses async somewhere inside (a sub-function) will cause your application to deadlock. It is extremely surprising that .NET does not handle this (abet novice) design mistake in a graceful way. (For example, checking if a thread is blocked before attempting to schedule tasks to it)
pjmlp 11y ago
Because the only thing Go did was bake CSP into the language, it is nice, but not a solution for every concurrency problem. While async/await allows for an abstraction over the lower level tasks, that are still exposed, in case one needs more control over the threading runtime. For example, in JS's case you can still dig into the Promise world if needed. Similarly in C#, Tasks / Dataflow and SignalR can also be used. Whereas in Go, correct me if I am wrong, outside CSP one needs to reach out to threads/mutex/semaphore directly.
- aikah 11y ago
  > Because the only thing Go did was bake CSP into the language, it is nice, but not a solution for every concurrency problem. I'm not sure I understand your sentence. Are you saying that communicating sequential process only works because it is first class in Go or that CSP is not a solution to every concurrency problem ?
  - pjmlp 11y ago
    It is not a solution to every concurrency problem. I tend to use languages that give library writers (almost) the same control as the language itself has. EDIT: To expand a little more into what I mean. In most languages that offer async/await, that is mostly syntactic sugar (with some compiler help) to the blessed task pool library. A good way to explore that is to see the parallel libraries available in C++, JVM, .NET, Haskell and OCaml worlds.

idibidiart 11y ago

CSP can be implemented on top of async/await, which itself is implemented on top of promise and generators. What does streaming APIs have to do with CSP per se?

findjashua 11y ago

for consuming 'streaming APIs', why not just use observables (rx.js etc)?

bklimt 11y ago
Observables are great, and are indeed the stream equivalent to Tasks. But the await/async keyword compilation doesn't support them. I think that's the parent post's point.
- josteink 11y ago
  I've seen stream-like constructs done with c# async and await and to me it even looked elegant. Could you expand on in what way you think async and await is insufficient with regards to streams? I'm genuinely curious.
  - colin_jack 11y ago
    Would you have a link to an example of a streaming API done elegantly with async? I'm interested to see what it looks like.
    - josteink 11y ago
      It was during a presentation on the NDC developer conference a few years back, when the feature was new to C#. I remember thinking it was one of the best presentations that year, but right now I don't remember what year it was, and I can't find any past agendas to search either. NDC posts their videos online after each conference, and I did a quick skim. I think it may be this session here, but I haven't double-checked: https://vimeo.com/43808831 https://vimeo.com/43808831 Edit: It was a 2-part session and it may also have been in second half. Link here: https://vimeo.com/43808833 https://vimeo.com/43808833
      - colin_jack 11y ago
        Much appreciated ta, will give it a look.

bklimt 11y ago

The one advantage of C#'s async/await over Go's CSP is that by exposing the underlying Tasks, you can take more control over how the continuations get executed. The result of this is that it's easy to have async code that all runs on the same thread (usually the UI thread) even while it calls a function makes a network request that gets scheduled to a background thread. Go's model doesn't give you as much control over which thread a particular operation gets assigned to. It's not theoretically impossible, I suppose, but it's hard to imagine what a simple API for it would look like. But yes, if this particular problem were solved in an elegant way, I would also prefer the CSP model. It makes it so you don't have to worry about which operations are async or not.

_wmd 11y ago
This was one of my main worries about Go when I evaluated it back in 2010. Most green threads implementations have an explicit determinism model, and it's typically straightforward to reason about and depend on execution order and suchlike, much as you can with plain asynchronous code, but with Go there didn't appear to be any guarantee when or how your code ran. In any case I suppose many styles of Go program will exhibit accidental determinism, but it still seems too difficult to depend on as randomness can be introduced simply by invoking the wrong function, or by using a different runtime version, which to me feels comparable to the hazards of raw multithreading.
novaleaf 11y ago
A huge problem with C#'s Async feature that I hope gets resolved (and, obviously that this failure pattern is not ported to Javascript): Explicitly blocking during a function that uses async somewhere inside (a sub-function) will cause your application to deadlock. It is extremely surprising that .NET does not handle this (abet novice) design mistake in a graceful way. (For example, checking if a thread is blocked before attempting to schedule tasks to it)

pjmlp 11y ago

Because the only thing Go did was bake CSP into the language, it is nice, but not a solution for every concurrency problem. While async/await allows for an abstraction over the lower level tasks, that are still exposed, in case one needs more control over the threading runtime. For example, in JS's case you can still dig into the Promise world if needed. Similarly in C#, Tasks / Dataflow and SignalR can also be used. Whereas in Go, correct me if I am wrong, outside CSP one needs to reach out to threads/mutex/semaphore directly.

aikah 11y ago
> Because the only thing Go did was bake CSP into the language, it is nice, but not a solution for every concurrency problem. I'm not sure I understand your sentence. Are you saying that communicating sequential process only works because it is first class in Go or that CSP is not a solution to every concurrency problem ?
- pjmlp 11y ago
  It is not a solution to every concurrency problem. I tend to use languages that give library writers (almost) the same control as the language itself has. EDIT: To expand a little more into what I mean. In most languages that offer async/await, that is mostly syntactic sugar (with some compiler help) to the blessed task pool library. A good way to explore that is to see the parallel libraries available in C++, JVM, .NET, Haskell and OCaml worlds.