Is there an article or book where the major "ways" of doing concurrency in different languages are explained and compared? E.g. thread process mutex semaphore etc. in Java et al, callback promise async await in JS, goroutine channel in Go, task async await plinq in C#, asyncio in Python, etc. It would be nice to have a general overview of these, what their pros and cons are and why.
Great news.<p>FYI Chrome will ship with async/await support[0] in the next stable version (55, so it's already on Chrome Canary).<p>[0]<a href="https://bugs.chromium.org/p/v8/issues/detail?id=4483" rel="nofollow">https://bugs.chromium.org/p/v8/issues/detail?id=4483</a>
Note that async functions <i>always</i> return native promises. So if you like your fast or sugary promise libraries, you can't make async functions return those promises. You are stuck with the native promises, which, as of now, are pretty slow in almost all engines in comparison to the heavily optimized promise library bluebird.<p>I guess we should just hope that engines will optimize their own promise implementations. This might not matter much in front-end apps, but absolutely does for Node apps.<p>Other than that, I believe it is time JS gets:
1. An actually useful try/catch (with pattern matching on the catched errors)
2. Standard stack traces across all engines<p>Those two will really help async/await.
I am a JS programmer and I have mixed feelings about this. I am not entirely sold on the stuff that comes <i>after</i> async/await. In particular, I am curious to know what folks here think about cancelable promises [1] and the try...else block that might be introduced. Or about async iterators [2], where you can `yield await` stuff.<p>[1] <a href="https://github.com/tc39/proposal-cancelable-promises" rel="nofollow">https://github.com/tc39/proposal-cancelable-promises</a><p>[2] <a href="https://github.com/tc39/proposal-async-iteration" rel="nofollow">https://github.com/tc39/proposal-async-iteration</a>
I'm really looking forward to not having to debug my code compiled to state machines.<p>Is there a good way to get Babel/Webpack to emit multiple versions of your code compiled with different features enabled, then load the right bundle?
I have one major misgiving about async-await - the regression in needing to do a try-catch if one isn't isn't a test situation. This is a terrible syntax to have to write to handle this.<p>That said, async functions also introduce a fundamental language shift in how one parses JS. One can now block execution to return a value, but no longer know if the innards of a function is blocking, which could mean that your function execution is blocked by an async execution. Instead of what one may know as async by looking at a promise or any other similar construct for handling async flow like observables, this will be the source of many bugs in developers' code as we shift in mindset, should this become popular. This would definitely improve readability of code written using continuation passing style though.<p>Minus the awful try-catch, I'm not necessarily against async-await being the norm, but its broad effects on how async code will be written should be recognized, especially considering that it doesn't solve a fundamental issue like something like observables do.
Am I alone in the boat that feels that the way that async/await is implemented in JS is a little wonky? I kind of prefer that you can do `await asyncFunc(...)` without having to denote the function itself as `async`, but I don't like that you can just call the `asyncFunc` without `await` and it would still potentially do something. In Python, when you `await` something, it actually runs the code, whereas running the function by itself just returns a Future that hasn't been started.<p>I feel like it's less difficult to shoot yourself in the foot with Python's implementation, because you know that if you're calling an asynchronous function, you have to `await` it or it won't work and won't have side effects. In JS, you could call the async function without awaiting it and it could have side effects which could produce subtle bugs that aren't easy to find.
Still not entirely sure what the big win with async/await is. Is it just a readability thing? Is there one "killer" case that demonstrates its superiority over callbacks?
Dear Javascript coders:<p>If you wind up writing the word "await" in your codebase more than once, you're doing it wrong. You will quickly see how futures/promises wind up taking over all of your code. This is a very good thing. You shouldn't need to block, ever.<p>Sincerely,<p>Scala coders