Anyone else bothered by the utter lack of semicolons in the example code? :D
Yes It's like reading English without periods It's frustrating
Async/Await will make code simpler
21–30 of 93 posts
Re: Async/Await will make code simpler
#22I 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 (callee convenience/error delegation).
I think I'm just going to stick to Promises for the time being, until I see some hidden usefulness of async/await syntax (which could totally happen. It took me a long time to realize how awesome promises are).
Re: Async/Await will make code simpler
#23try catch try catch try catch try catch try catch try catch try catch try catch
better than then().catch().then().catch().then().catch().then().catch()
Re: Async/Await will make code simpler
#24same example with async control flow library and node style callback conventions function getUserInfo(callback) { async.parallel([api.getUser, api.getFriends, api.getPhoto], callback) }
Even with a library like async there will be so much boilerplate, since you need to handle (or pass) errors every step of the way. With async/await you only need to deal with errors at the level you actually care about them (using the language build in try/catch block).
In the example above, any error will be passed to the callback sent to getUserInfo - i.e., where you care about it.
Re: Async/Await will make code simpler
#25I really don't see the need for such a syntax.
If I say:
Foo foo = someFoo();
...
String content = foo.getContent();
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 this functionality in a loop of independent executions (when the results of any given loop don't depend on the results of prior loops):
for(Foo foo: asyncFoos()){
Foo foo = someFoo();
...
result.add(foo.getId(), foo.getContent());
}
Now you can either replace this "for" with some sort of "for-each" type of block, or you can go async all the way and treat "for" as "for-each" and any referenced result of a prior iteration as yet another async value.
That covers sets and singletons, I imagine that any other situation that needs to be dealt with can also be covered on the compiler side of things with only minimal changes to syntax.
Re: Async/Await will make code simpler
#26Anyone else bothered by the utter lack of semicolons in the example code? :D
If you've got a halfway decent linter, semicolons are just clutter. https://eslint.org/docs/rules/no-unexpected-multiline is the sort of thing that makes semicolon free style practical.
Re: Async/Await will make code simpler
#27I 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…
You can abstract your try / catch logic to a higher level to fix this easily. make all promises extend from a base promise function that either returns a result, or null (or an error, you can make it more complex). Then,
let data = await customPromise()
if(!data) return
Re: Async/Await will make code simpler
#28I 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…
I'd rather user try/catch than endless chains of then().
Re: Async/Await will make code simpler
#29I 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…
Here's a great article somebody posted on HN awhile back, "What Color is Your Function?" -- http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... The proper abstraction is threads--i.e. a stack structure used for the storage of temporary values, which is shared by nested function invocations as well as similar structured programming constructs like if/else conditionals that together represent a singular thr…
light-weight multithreading that enters a scheduler loop when I/O would block is great, and I haven't seen any advantages of async/await compared to that, other than ease of implementation (you make the programmer or library author implement multithreading, rather than implementing it in your runtime).
Promises are at least slightly more interesting because they can functionally compose in various ways (but most of the time it's just a dozen then() calls in a row, and threading would have been better).
Re: Async/Await will make code simpler
#30I 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…
> However, I recently started using async/await in TypeScript, and the result seems to be try/catch statements everywhere.
Why do you have try/catch everywhere? Unless you're actually going to handle the error, you shouldn't do anything as it will bubble up till it gets to a piece of the app that can handle it. For web apps a lot of the time that's a single request level handler to return a 5XX.
> 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 (callee convenience/error delegation).
Eh? Besides the addition of the "async" keyword on the top level function, it's always less verbose.
Where I think things get a bit tricky is awaiting the composition of Promises to support parallel processing (as opposed to just 1) await foo() 2) await bar() ...). It's best to treat that like regular composition and simply await the result.