110

It is fair to say promises are just syntactic sugar. Everything you can do with promises you can do with callbacks. In fact, most promise implementations provide ways of converting between the two whenever you want. The deep reason why promises are often better is that they're more composeable, which roughly means that combining multiple promises "just ...


106

Nope. They're really handy for implementing Observers and making sure that classes are closed to modification. Let's say we have a method that registers new users. public void Register(user) { db.Save(user); } Then someone decides that an email should be sent. We could do this: public void Register(user) { db.Save(user); emailClient.Send(...


65

Async/await is exactly that automated management that you propose, albeit with two extra keywords. Why are they important? Aside from backwards compatibility? Without explicit points where a coroutine may be suspended and resumed, we would need a type system to detect where an awaitable value must be awaited. Many programming languages do not have such a ...


53

Nope. A classic example of events being used in non-GUI logic are database triggers. Triggers are code that gets executed when a given event happen (INSERT,DELETE, etc). Seems like an event to me. This is the Wikipedia definition of event: In computing, an event is an action or occurrence recognized by software that may be handled by the software. ...


35

Asynchronous programming is much more of a philosophy than just another programming trick. While, your last question attracted answers mainly about programming aspects and my answer was a disconnected loner for being mostly theoretical, I am trying to give you a fresh perspective building on the same line but explanations rather than just references. ...


32

No, async + await != sync, because of continuation From MSDN 'Asynchronous Programming with Async and Await (C# and Visual Basic)' Async methods are intended to be non-blocking operations. An await expression in an async method doesn’t block the current thread while the awaited task is running. Instead, the expression signs up the rest of the ...


27

Event-based programming is actually also used for highly performant server programming. At a typical server workload, much of the time processing a result actually comes from I/O. For example, pulling data off a (7200 RPM) hard disk drive can take up to 8.3 ms. For a modern GHz processor, that would equate to ~1 million clock cycles. If a CPU were ...


26

It doesn't. Just taking a callback or passing a callback doesn't mean it's asynchronous. For example, the .forEach function takes a callback but is synchronous. var available = false; [1,2,3].forEach( function(){ available = true; }); //code here runs after the whole .forEach has run, //so available === true here The setTimeout takes a callback too ...


25

Accoding to an Anders Hejlsberg interview for Channel 9 about Asynchronous Programming async/await in C# takes inspiration on async worflows in F#. In case you don't know, Anders Hejlsberg is the lead architect of C#, and has also worked in other languages including TypeScript. According to Don Syme, on his blog, F# async workflows take inspiration from ...


23

The secret of the "magic" is that the events that you are assigning the callbacks to are asynchronous. They're implemented "under the hood" to take care of whatever they're doing (such as retrieving something from a remote server) in the background, outside of the JS sandbox. And then once they're done with their work, they give the JS engine a message to ...


21

What you are missing, is the purpose of async operations: They allow you to make use of your waiting time! If you turn an async operation, like requesting some resource from a server, into a synchronous operation by implicitly and immediately waiting for the reply, your thread cannot do anything else with the waiting time. If the server takes 10 ...


17

When Node.js is described as "non-blocking", that specifically means that its IO is non-blocking. Node uses libuv to handle its IO in a platform-agnostic way. On Windows, it uses IO completion ports, on Unix, it uses epoll/kqueue/select/etc. So, it makes a non-blocking IO request (which may have a background thread monitoring, but this is never exposed to ...


17

One issue I see using Task.WhenAll is that it does not return results But it does return the results. They'll all be in an array of a common type, so it's not always useful to use the results in that you need to find the item in the array that corresponds to the Task that you want the result for, and potentially cast it to its actual type, so it might not ...


14

While you may have 4 CPUs, you have only one hard-drive (unless you don't). The total performance will therefore be limited by your disk drive's read/write rate. Multiple threads isn't going to change that. Having a single separate thread handle all the file IO will allow your application to remain responsive while still getting things done asynchronously. ...


13

In general, any function that does networking or uses timers to do things over a period of time will be asynchronous. If the function takes a callback, you can look at what the callback is used for and usually it will be obvious whether is is asynchronous or not. If the function does not offer a callback, then it has no way of communicating asynchronous ...


13

Some do. They're not mainstream (yet) because async is a relatively new feature that we've only just now gotten a good feel for if it's even a good feature, or how to present it to programmers in a way that is friendly/usable/expressive/etc. Existing async features are largely bolted onto existing languages, which require a little different design approach....


12

Actor Model The actor model is computer science strategy for building applications that handle lots of concurrent computation and stateful processing. It's not the only strategy but it's a very well tested, simple, and reliable approach that moves computation into actors, which communicate through messages that they process one-at-a-time and in order. Akka ...


12

There are languages that do this. But, there is actually not much of a need, since it can be easily accomplished with existing language features. As long as you have some way of expressing asynchrony, you can implement Futures or Promises purely as a library feature, you don't need any special language features. And as long as you have some of expressing ...


11

C#'s Task is somewhere halfway between Java's Future and CompletableFuture. The Result property is equivalent to calling get(), ContinueWith() does the things the massive array of continuation functions on CompletableFuture does (add some Task.WhenAny and Task.WhenAll in there). But complete(T) has no equivalent (use a TaskCompletionSource), nor does cancel()...


10

Events are also heavily used in network programming (e.g. Nginx) to avoid expensive busy-wait loops and instead provide a clean interface to know exactly when a certain operation is available(I/O, urgent data etc). This is also a solution to the C10k problem. The basic idea is to provide the OS a set of sockets (i.e. network connections) to monitor for ...


9

Your question is already answered in the SO question you linked. The purpose of async/await is to make it easier to write code in a world with many high latency operations. The vast majority of your operations are not high latency. When WinRT first came out, the designers were describing how they decided which operations were going to be async. They ...


9

Are you aiming at making a general-purpose Javascript to C automatic translator (that is, a compiler from Javascript to C)? This is quite challenging and will take you several years of work, in particular if you want to make an efficient Javascript to C compiler (something which won't be much slower than most current Javascript implementations) Notice that ...


9

Repeat after me: REST and asynchronous events are not alternatives. They're completely orthogonal. You can have one, or the other, or both, or neither. They're entirely different tools for entirely different problem domains. In fact, general purpose request-response communication is absolutely capable of being asynchronous, event-driven, and fault ...


9

I feel that c# has become a very wordy language and I'm not happy to have to code in the async style like this. Oh, but that is not wordy at all. You are not writting something like this: client.GetAsync("http://www.nzherald.co.nz/").Then ( response => response.Content.ReadAsStringAsync().Then ( pageContents => { ...


8

Promises were made to solve problems like this; they work really well in functional languages (I've personally used them extensively in Javascript, where curiously jQuery actually has the worst implementation of them - see this comparison). The weird thing about using promises is accepting that things are easier when you make everything use them. I will ...


8

The most common example of Reactive programming that I've heard about is a spreadsheet program that has computed values. Personally, I would think about a spreadsheet more as a hybrid between functional and dataflow programming, but I can see how you can think about reactively. What's asynchronous there or requires streams in that case? There is an ...


7

The way that I would probably approach this would be to focus less on providing perfect results, and instead focus on a best-effort approach. This would result in at least the following changes: Convert the logic that currently starts a re-parse to request instead of initiate. The logic for requesting a re-parse may end up looking something like this: IF ...


7

When you call it like this: await GetChecksum(1,@"E:\Files\ISO\5gbfile.iso"); await GetChecksum(2,@"E:\Files\ISO\4gbfile.iso"); await GetChecksum(3,@"E:\Files\ISO\3gbfile.iso"); await GetChecksum(4,@"E:\Files\ISO\10mbfile.iso"); It creates the first task, then waits for it to complete, then creates the second task, then waits for it to complete, etc. When ...


7

This is where the monadic properties of Eithers come in handy (although you don't have to understand monads to take advantage of them). Most functional programming languages have a way to easily write this sort of chaining. In Haskell it's do notation. In Scala it's for comprehensions. Since I'm more familiar with Scala, I'll demonstrate that below. val ...


7

They do (well, most of them). The feature you're looking for is called threads. Threads have their own problems however: Because the code can be suspended at any point, you can't ever assume that things won't change "by themselves". When programming with threads, you waste a lot of time thinking about how your program should deal with things changing. ...


Only top voted, non community-wiki answers of a minimum length are eligible