posterus VS boxed

Check out these; - https://github.com/mitranim/posterus - https://github.com/timgit/pg-boss - https://github.com/FirebaseExtended/firebase-queue - https://www.npmjs.com/package/rabbit-queue

Async/Await covers the 80% of use cases for async logic in JS. Most people aren't really using promises as multicast references. They don't call `then` in one place, hang on to the promise reference, then call `then` again somewhere else (perhaps to represent a cached value); they call `then` once on the reference because it's just a moment in a composite operation.

It's for this reason that I think this library[0] is the more appropriate abstraction for that same 80% of use-cases, as its more memory efficient since you can represent the same composite operation that generates multiple promise references with a single object (a unicast reference instead). I haven't learned Rust but apparently the author bases this on Rust's ownership principle.

[0]https://github.com/mitranim/posterus

https://github.com/mitranim/posterus#taskdeinit

I was happy when Promise became available, but in retrospect I'd wish we would have skipped ahead and gotten Observable (e.g: https://rxjs.dev/) instead to enable more powerful functionality and composition etc.

In Typescript dealing with rejection is also painful since rejection reasons can't be guaranteed to be Error even when you always take care of that. And it can't help you guarantee that you're handling all types of errors thrown. For that purpose I'm thinking of using https://github.com/supermacro/neverthrow#readme or https://swan-io.github.io/boxed.

Agree that try/catch is verbose and not terribly ergonomic, but my solution has been to treat errors as values rather than exceptions, by default. It's much less painful to achieve this if you use a library with an implementation of a Result type, which I admin is a bit of a painful workaround, but worth it. I've recently been using: https://github.com/swan-io/boxed.

By far the greatest benefit is being able to sanely implement a type-safe API. To me, it is utter madness throwing custom extensions of the Error class arbitrarily deep in the call-stack, and then having a catch handler somewhere up the top hoping that each error case is matched and correctly translated to the intended http response (at least this seems to be a common alternative).