3 ms·
I don't understand your concern. When you say 'Upon calling something_async, the code starts waiting and blocks further execution until it is ready', you're des
by _sh 17y ago
I don't understand your concern. When you say 'Upon calling something_async, the code starts waiting and blocks further execution until it is ready', you're describing a synchronous call. Indeed window.confirm is a synchronous function--nothing is executed until it returns.
And yes, both asynchronous and synchronous operations have their place, umm, except perhaps in Haskell where things get funky. Chaining async operations together in javascript can be tedious, but its easy enough to write a helper function to handle it for you. Every javascript app I've written that uses AJAX always has some form of createCallback(context, function, arguments) function.
- xal 17y agoRe-read my example. All 3 db queries are run in parallel however the code does not continue if you access one of the values until the value is available. In a typical web application you usually get 3-5 things from the db, then you start rendering the templates. Each DB query waits for completion, then it starts the next which is a huge waste of time. In fact the system can easily start the parser and template renderer while the DB queries run and all the data will likely be available once it's accessed. This means you have all the benefits of synchronous processing with the majority of the advantages of async. The vast majority of web applications would likely very rarely block a thread in such an architecture. I'm very surprised that not more languages implement this pattern. Maybe i'm missing something but this is the major feature of GO, except that almost everyone missed it and focused on the fact that it compiles fast and looks like c
- Hexstream 17y agoSeems like you the dataflow paradigm is exactly what you'd need. With dataflow, trying to read a variable that doesn't know its value yet blocks until the value becomes known.