71–80 of 93 posts
Async/await can be used to implement coroutines, but IIRC only if you wrap all of the code that might be called in async/await as well, and this catch makes them practically useless. Why not just provide proper coroutines?
While we're at it why coroutines? You can implement coroutines, generators, even try/catch and return given continuations [0].
Earlier quoted context omitted.
> I've made plenty of stupid mistakes where the two 'faces' of the abstraction don't marry up, and it's frustrating. Would you mind sharing any of these?
I'm talking really stupid, small, frustrating things, mostly at the interfaces. I read a return x at the bottom of one function and call the function elsewhere and try to use x , but oh wait no.. it was an async function so I've really got Promise . Generally it's just because of the leaky abstraction making very fast mental mapping of code a bit harder.
Earlier quoted context omitted.
This makes little sense. You don't need more try..catch blocks than you would normally have a catch promise clause. Exceptions bubble up.
I'm finding that with client side async, the awaited behaviour is often external, heterogeneous and unreliable. When an operation fails, it typically requires a state-machine transition to a failed/retry state or fallback service rather than just bubbling up to a top level handler like a coding error i.e. there is something specific you need to do unlike typical exceptions. Retrofitting a code base with async I concu…
Earlier quoted context omitted.
Multithreading is not synonymous with preemptive scheduling. That's an entirely different issue. A chain of promises or async/await functions is no better in this respect than so-called green threading, and in many cases is worse than a cooperatively scheduled framework that provides more explicit control over the points at which thread execution can switch. For example, a system built on stackful coroutines where th…
Here's the thing, if you can call functions that themselves can yield - you are in a shared memory multithreading model, where you can never guarantee for any function not to yield, so you have to use synchronization for that guarantee with all the same issues.
I really don't see the need for such a syntax. If I say: Foo foo = someFoo(); ... String content = foo.getContent(); I really don't care if foo was returned when I called someFoo(), I only care that getContent() is not attempted until after foo is defined. There's little reason for me - in this situation at least - to need this async functionality to be explicitly stated. The biggest problem I see is a when you use t…
You may not care, but the computer does!
Earlier quoted context omitted.
I'm finding that with client side async, the awaited behaviour is often external, heterogeneous and unreliable. When an operation fails, it typically requires a state-machine transition to a failed/retry state or fallback service rather than just bubbling up to a top level handler like a coding error i.e. there is something specific you need to do unlike typical exceptions. Retrofitting a code base with async I concu…
You should make your API client layer be able to retry operations (and maybe track the status of a network connection) rather than write catch/then() manually.
Exceptions work best when the error is fatal for the local scope but responses from external services aren't like that. The general problem is that the dividing line between errors and information becomes too blurry - your error might only be information to me. A simple example is where something like axios will (by default) throw on 404 responses but an external api might use 404 to indicate a resource does not exist. If your app logic makes a decision based on this information, you will find yourself using exception handlers for control flow despite not experiencing any actual errors.
I heard Doug Crockford talk about how he doesn't think async/await is that great an idea on a podcast a while ago. His argument was that it's an unclean abstraction - it gives you access to 'features' of synchronous imperative syntax (lines in a function always execute in order, try-catch blocks, etc) but it remains conceptually and literally promises all the way down. Therefore, all await 'calls' are really non-bloc…
The same exact arguments and pitfalls coming up
I really don't see the need for such a syntax. If I say: Foo foo = someFoo(); ... String content = foo.getContent(); I really don't care if foo was returned when I called someFoo(), I only care that getContent() is not attempted until after foo is defined. There's little reason for me - in this situation at least - to need this async functionality to be explicitly stated. The biggest problem I see is a when you use t…
One of the best things about JS/Node is that you can wait on I/O from different sources at the same time and since the async/await syntax is just sugar over Promises, you can do things like:
const [user, notifications, messages] = await Promise.all([
getUser(),
getNotifications(),
getMessages(),
]);
const user = getUser();
const notifications = getNotifications();
const messages = getMessages();
I really don't see the need for such a syntax. If I say: Foo foo = someFoo(); ... String content = foo.getContent(); I really don't care if foo was returned when I called someFoo(), I only care that getContent() is not attempted until after foo is defined. There's little reason for me - in this situation at least - to need this async functionality to be explicitly stated. The biggest problem I see is a when you use t…
I personally think that the syntax is great considering it's being added to an existing language. await/async allows you to opt-in to having your code behave in a synchronous-like manner, when you want it to. One of the best things about JS/Node is that you can wait on I/O from different sources at the same time and since the async/await syntax is just sugar over Promises, you can do things like: const [user, notific…
I was super excited about async/await when it first came out. I hadn't really understood the point of Promises, but async/await looked simple and useful. However, I recently started using async/await in TypeScript, and the result seems to be try/catch statements everywhere. Code using async/await seems to be more verbose and unruly than just sticking to Promises, which I now appreciate the elegance of much more (call…
hmm were you previously using Promise.catch for flow control? It's basically as bad as using exceptions for flow control, just with with a different set of bubbling / propagation problems. Unless you're dealing with truly exceptional conditions you should not be throwing inside your promises, thus no need for try / catch when converting them to async/await.