Hacker News new | ask | show | jobs
by koolba 3347 days ago
Typescript plus async/await is a beautiful solution to both the async story and typing story.
3 comments

I don't think asnyc/await is a good solution to asynchronous programming. Lua, Go et al are more what I was thinking of as good examples of asynchronous programming. See http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

And I addressed some concerns with Typescript in a sibling comment. It is much better than plain Javascript, though.

async/await is still based on promises, and promises are a naive/simplistic answer to the problem.

It works fine for simple cases, but those are cases that were simple to begin with (Ok, maybe they would not be fine with CPS, but async/await is just thin sugar over promises).

To really solve the async problem, you need either Observables or monadic constructs. The former is much more mainstream and mature in the JS world right now. It's not as cute as async/await and you'll be typing more functions, but it really solves the problem altogether.

The problem I experienced with async/await and Typescript was always the lack of built-in support for promises among the libraries I was using. Once I had to use something like promisifyAll() I lost any type information I had about the library in question.

Is there any better workaround to that these days?

This is changing pretty steadily. For example, the AWS SDK has TypeScript types packaged now and a promise interface. Compare this the boto3, the Python SDK, which has had a story open for years(?) to add async support with no official solution.

Node.js's own libraries are a mix of events and callbacks. Some of it can been "promisified", however they have yet to start a real async conversion AFAIK. I've had to wrap some of this stuff to create async interfaces for my own code.

Not really but I also don't see it as that much of a problem. The libraries I use either provide a Promise based interface or I've written my own as a thin veneer atop a callback interface.

Ditto for apply your own types atop the results. Most are already there and only a few edge cases need to be added.

I had a somewhat different experience. Most of the libraries I used lacked types in the library itself. There were types provided by DefinitelyTyped, but they were often incomplete or out of date, and I think a wrong type definition can be worse than none at all.

As far as writing your own types on top of those libraries, how do you ensure any amount of correctness?

Am I missing something important here?