4 ms·
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. T
by 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 agoYou know, this kind of BS about Java is a little tiresome.
- outside1234 13y agosometimes the truth hurts
- pjmlp 13y agoWhat 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 agoAw 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 agoF# 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 agoBy the way, how do F#'s async workflow compare to ClojureScript? Are they equally powerful?
- klibertp 13y agoIn 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 agoClojure/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.
- swannodette 13y agoAs Brandon alludes below monadic designs generally have allocation overheads, this is why C# uses state machines. So while they may be equivalent in some abstract sense of "power" one ends up being more efficient in practice.
- sker 13y agoYes, C# tends to copy F# features in the way of compiler-syntactic-sugar. I wonder if Type Providers will be next. Async/await have been around for a couple of years and I haven't heard of the next big C# feature, other than Roslyn.