Synchronous vs Asynchronous languages

Question

In last 1 year I was working on Java and flex. While coding flex, most of my code parts went for a toss since its asynchronous. It made me to think about the real advantages and disadvantages of synchronous executing languages vs asynchronously executing ones.

What are the areas where they are stronger compared to other and what are the areas they falls?

Answer 1

I've spent most of the last year coding in Silverlight, which means I've spent a good deal of time thinking through (and fighting with) the same issues you're describing.

In brief, as other folks have pointed out, the real strength to the asynchronous model is its ability to create robust systems that interoperate well with the real world. Nobody could realistically use a Silverlight (or Flash) application if the UI thread came to a halt every time it took a few seconds for a web service call to return.

The biggest downside is that it the resulting code is complex and difficult to troubleshoot. Things like error handling are a PITA, but the most annoying stuff I've had to deal with is coordinating responses from multiple asynchronous calls. If, say, you need information from call A before making call B, and you need information from call B before making call C (and so forth), the resulting code looks really unpleasant, and is susceptible to all sorts of weird side-effects. There are techniques for making all this stuff work, and even reasonably clean, but if you're coming from the synchronous world (as I was), it's a significant learning curve. (And it doesn't help that Microsoft pushes events as the way to deal with WCF calls when callbacks, in my opinion, are much cleaner and less susceptible to the sort of weird side-effects I was talking about.)

(And yes, other folks are correct in saying that it's not the language that's asynchronous so much as that particular frameworks require constructing your code in an asynchronous manner -- but I get what you mean.)

Update 2014.09.23 -

I've done a lot more work with a variety of asynchronous frameworks since I wrote the answer above (as has probably everybody else who's done any web coding), and thought I'd add a few additional random notes:

• If you're using a language like C# or F# that has first-class asynchronous support, a lot of this gets a whole lot easier, at least, once you wrap your head around the weird async/await patterns. Being able to loop easily around asynchronous calls, and wrap the whole thing with a simple try/catch, is amazing if you've ever had to do it the old way.

• If you're not using a language with first-class async support, start using whatever promise or future or task support that the language does provide (e.g., JQuery's $.Deferred(), or Angular's $q.defer(). Those are a lot cleaner and provide better structure than what you typically get with callbacks.

• Asynchronous code is critical for writing scalable server-side systems. One of the biggest issues with making a typical web server scale well is that it starts running out of threads, at least, it does if it dedicates a thread to reach incoming request. If that thread stalls, because it's waiting for a long-running synchronous call to finish, it's completely unavailable for helping out with anything else. Much better is to make your web server code async, so that when you're waiting on a DB call to return, that thread can go service half a dozen other requests while the DB is going and doing whatever DB's do. At this point, for highly scalable systems, async is the only game in town. (Just ask any Node aficionado.)

Answer 2

(Leaving aside the semantics level discussion i.e. "sync/async language")

A "framework" built on a "language" (whatever it is) should be able to handle such cases (sync/async programme flow) in order to be useful (read: $ wise).

Asynchronous idioms are appropriate at every scale.

At large scale, asynchronous techniques help build reliable systems because the real world is anyhow asynchronous in nature. In other words, one needs to think in "asynchronous thoughts" to cope with real-life situations such as failures, losses, delays etc.

Even on a smaller scale (e.g. GUI application), events (such as "mouse clicks") tend to be "asynchronous". Of course they are "serialized" at some point (in order to be processable by an application running some software) but it doesn't change the fact that events (probably) occurred "asynchronously" with regards to the flow of the programme in question.

Answer 3

I think it's not about the language, but about the framework.

Counter-case in point:

When writing 'Classic Mac' (MacOS 9 and before) applications in C (a 'synchronous' language if there ever was one), you don't have preemptive multithreading, so all potentially blocking system calls have an async counterpart, where you fill a block of data with parameters including a callback function. Then you do the system call (which would return immediately), and your callback would be called asynchronously (in what's called 'interrupt level'). It wasn't uncommon that a callback would do another async system call, creating a long background thread that ran asynchronously with the main one.