11 ms·

Yes a thousand million times. This is the reason why people love golang and why there's a lot of excitement about core.async in the Clojure community, particula

Yes a thousand million times. This is the reason why people love golang and why there's a lot of excitement about core.async in the Clojure community, particularly for ClojureScript where we can target the last 11 years of client web browser sans callback hell: http://swannodette.github.io/2013/07/12/communicating-sequential-processes/ http://swannodette.github.io/2013/07/12/communicating-sequen... Having spent some time with ClojureScript core.async I believe the CSP model actually has a leg up on task based C# F# style async/await. We can do both Rx style event stream processing and async task coordination under the same conceptual framework.

danabramov 13y ago
This sounds sweet. In my book, C# designers have a history of striking a good balance between simplicity and flexibility. This however always leaves me eager to look at Haskell/ClojureScript/other languages where concepts that C# borrowed and simplified are taken to the full (such as monads, iterators, CSP, etc).
- sker 13y ago
  The C# designers outdid themselves this time. I'm surprised they managed to made this feature so simple and succinct, especially for an "enterprise" language. Those two little words (async/await) seem like something I would expect from a language like Python or Ruby. Had it been Java, it would be called AsynchronousBureaucraticProccessDispatcherFactoryFactoryFactory.
  - peterashford 13y ago
    You know, this kind of BS about Java is a little tiresome.
    - outside1234 13y ago
      sometimes the truth hurts
      - pjmlp 13y ago
        What people like to accuse Java for, I have seen enterprise architects do such examples in C, Perl, C++, Java, C# and about any other language used in enterprise context.
  - general_failure 13y ago
    Aw come on. Have you ever programmed in Java? Anybody who has written any java code knows that class name is wrong. AsynchronousBureaucraticProccessDispatcherFactoryFactoryFactoryInterfaceProvider There I fixed it for you. And of course you have to specify the provider in the META-INF/async file.
  - MichaelGG 13y ago
    F# implemented this many years before (6 years ago), and as a library, just by providing the proper language feature, workflows, and a default async implementation. In comparison, C# adds special compiler keywords for one specific example, just like they did with LINQ. That seems rather ugly IMO. Providing building blocks and letting libraries fill things in is a lot nicer. This is more of a "C#'s finally catching up with basic features".
    - danabramov 13y ago
      By the way, how do F#'s async workflow compare to ClojureScript? Are they equally powerful?
      - klibertp 13y ago
        In F# workflows are just a syntactic sugar for monads, much like Haskell 'do' notation. You can get continuation monad (workflow) in F# easily. I don't know what ClojureScript uses, but it doesn't seem very likely that it has more powerful mechanism :)
        brandonbloom 13y ago
        Clojure/ClojureScript now has core.async, which is a Go-style implementation of CSP with coroutines and channels. Like C#, core.async uses a lexical compiler transform to produce a finite state machine for the co-routine. Unlike C#, Clojure can achieve this with a user-level macro, instead of a compiler change. Both C# and core.async differ from Go, in that Go's coroutines have dynamic extend, by virtue of being heap-allocated stacks with a custom scheduler. In practice, this has a minor impact on higher-order usage of co-routines, but is a smaller problem than you'd think, it's generally advisable to minimize higher order usage of side effects. Both C# and Go's approaches can be implemented as Monads, yes. However, Monads are a significantly more abstract thing than either CSP or C#-style Tasks. The do-notation is barely concealed continuation-passing style, which is generally less pleasant to work with than traditional imperative constructs for side effects such as send & receive. "More powerful" isn't a really useful measurement for practical use.
benhoyt 13y ago
Yeah, C# await/async is cool. But isn't Google Go's approach nicer? Keep standard lib calls blocking as is, and use the "go" statement when you want to run something async? It avoids all the extra DoWhateverAsync() API functions. See http://stackoverflow.com/a/7480033/68707 http://stackoverflow.com/a/7480033/68707 What's the Go equivalent of "await"? I.e., like the "go" statement but asynchronously wait for the function to return and get its value?
- chaosphere2112 13y ago
  ci := make(chan int) go func(ci) <-ci
  - carbocation 13y ago
    If you're using `ci` as just a semaphore, you should use a struct, since those use even less memory than an int in go.
- carbocation 13y ago
  I think that WaitGroups or possibly just reading from a semaphore channel might do the trick for you in go.
- skybrian 13y ago
  The difference is that Go has what looks like preemptive scheduling for goroutines (and will eventually be truly preemptive; see [1]) while await is more like cooperative multitasking. If you're writing in Go, you should use channels (or mutexes) to avoid race conditions: "share by communicating". With a single-threaded language using await, it's safer to modify common data structures without locks, although you should be aware that calling a function via "await" gives others task the opportunity to modify your data. So "await" appearing in the code explicitly warns you that pseudo-multitasking is happening. In Go, preemption can (in theory) happen at any time, plus there are multiple threads. [1] http://honnef.co/posts/2013/08/what_s_happening_in_go_tip__2013_08_15_/ http://honnef.co/posts/2013/08/what_s_happening_in_go_tip__2... Edit: Go isn't truly preemptive in 1.1.
- deleted 13y ago

danabramov 13y ago

This sounds sweet. In my book, C# designers have a history of striking a good balance between simplicity and flexibility. This however always leaves me eager to look at Haskell/ClojureScript/other languages where concepts that C# borrowed and simplified are taken to the full (such as monads, iterators, CSP, etc).

sker 13y ago
The C# designers outdid themselves this time. I'm surprised they managed to made this feature so simple and succinct, especially for an "enterprise" language. Those two little words (async/await) seem like something I would expect from a language like Python or Ruby. Had it been Java, it would be called AsynchronousBureaucraticProccessDispatcherFactoryFactoryFactory.
- peterashford 13y ago
  You know, this kind of BS about Java is a little tiresome.
  - outside1234 13y ago
    sometimes the truth hurts
    - pjmlp 13y ago
      What people like to accuse Java for, I have seen enterprise architects do such examples in C, Perl, C++, Java, C# and about any other language used in enterprise context.
- general_failure 13y ago
  Aw come on. Have you ever programmed in Java? Anybody who has written any java code knows that class name is wrong. AsynchronousBureaucraticProccessDispatcherFactoryFactoryFactoryInterfaceProvider There I fixed it for you. And of course you have to specify the provider in the META-INF/async file.
- MichaelGG 13y ago
  F# implemented this many years before (6 years ago), and as a library, just by providing the proper language feature, workflows, and a default async implementation. In comparison, C# adds special compiler keywords for one specific example, just like they did with LINQ. That seems rather ugly IMO. Providing building blocks and letting libraries fill things in is a lot nicer. This is more of a "C#'s finally catching up with basic features".
  - danabramov 13y ago
    By the way, how do F#'s async workflow compare to ClojureScript? Are they equally powerful?
    - klibertp 13y ago
      In F# workflows are just a syntactic sugar for monads, much like Haskell 'do' notation. You can get continuation monad (workflow) in F# easily. I don't know what ClojureScript uses, but it doesn't seem very likely that it has more powerful mechanism :)
      - brandonbloom 13y ago
        Clojure/ClojureScript now has core.async, which is a Go-style implementation of CSP with coroutines and channels. Like C#, core.async uses a lexical compiler transform to produce a finite state machine for the co-routine. Unlike C#, Clojure can achieve this with a user-level macro, instead of a compiler change. Both C# and core.async differ from Go, in that Go's coroutines have dynamic extend, by virtue of being heap-allocated stacks with a custom scheduler. In practice, this has a minor impact on higher-order usage of co-routines, but is a smaller problem than you'd think, it's generally advisable to minimize higher order usage of side effects. Both C# and Go's approaches can be implemented as Monads, yes. However, Monads are a significantly more abstract thing than either CSP or C#-style Tasks. The do-notation is barely concealed continuation-passing style, which is generally less pleasant to work with than traditional imperative constructs for side effects such as send & receive. "More powerful" isn't a really useful measurement for practical use.

benhoyt 13y ago

Yeah, C# await/async is cool. But isn't Google Go's approach nicer? Keep standard lib calls blocking as is, and use the "go" statement when you want to run something async? It avoids all the extra DoWhateverAsync() API functions. See http://stackoverflow.com/a/7480033/68707 http://stackoverflow.com/a/7480033/68707 What's the Go equivalent of "await"? I.e., like the "go" statement but asynchronously wait for the function to return and get its value?

chaosphere2112 13y ago
ci := make(chan int) go func(ci) <-ci
- carbocation 13y ago
  If you're using `ci` as just a semaphore, you should use a struct, since those use even less memory than an int in go.
carbocation 13y ago
I think that WaitGroups or possibly just reading from a semaphore channel might do the trick for you in go.
skybrian 13y ago
The difference is that Go has what looks like preemptive scheduling for goroutines (and will eventually be truly preemptive; see [1]) while await is more like cooperative multitasking. If you're writing in Go, you should use channels (or mutexes) to avoid race conditions: "share by communicating". With a single-threaded language using await, it's safer to modify common data structures without locks, although you should be aware that calling a function via "await" gives others task the opportunity to modify your data. So "await" appearing in the code explicitly warns you that pseudo-multitasking is happening. In Go, preemption can (in theory) happen at any time, plus there are multiple threads. [1] http://honnef.co/posts/2013/08/what_s_happening_in_go_tip__2013_08_15_/ http://honnef.co/posts/2013/08/what_s_happening_in_go_tip__2... Edit: Go isn't truly preemptive in 1.1.
deleted 13y ago