Viewing profile — Mitranim

Added more examples and motivations for cancelation: https://github.com/Mitranim/posterus/blob/17c89694ecdce4633f...

Added a readme section on Rx: https://github.com/Mitranim/posterus/blob/17c89694ecdce4633f...

It sounds like you're saying "explicit FSMs are strictly more powerful than promises/coroutines". Which is true. However, they're inherently difficult to program. In my view, the k…

That's what the mapping operators are for: `.mapResult` (same as `promise.then`), `.mapError` (same as `promise.catch`), or `.map`. The latter has an errback signature, like Node.j…

Glad it works for you! Kind of answered in another subthread: https://news.ycombinator.com/item?id=14963524

Interesting! Nice that the approach is known, and others are being discussed. I should check GTOR again. Multicast cancelation based on refcounting doesn't look right to me. I expl…

This is news to me. Last time I tried RxJS, was unable to get a usable core less than 100 KB minified (I don't use gzip as a metric). Would consider 20-30 KB. Might want to look ag…

For one operation, sure. It doesn't work when you want to compose multiple async operations, wait until all are finished, or race several of them to completion (e.g. useful operati…

No disagreement here. Rx observables are strictly more powerful than promises/futures/streams. But why start with the superset? I don't think it's good design. Consider the perspec…

This is news to me. Last time I looked into RxJS, I was unable to get a minimum useful core of less than 100 KB minified. Might want to look again, thanks!

Correct. Most websites are better off with static HTML or server-side rendering and the least possible amount of JS. However some apps DO have to be fat. And don't forget about Nod…

Doesn't sound as ergonomic as just returning a cancelation function in a future initialiser. Not seeing any other advantages, either. Am I missing some?

Agreed, often it doesn't matter. Sometimes it DOES matter (high latency / low bandwidth / weak device), and then your program is slower than it could be. Why not pursue async primi…

We need a standard destructor interface instead of choosing a different word every time. Cancel, close, destroy, drop, unmount, they do the same thing. If we settled on ONE destruc…

Depends on use case. Sometimes you're surprisingly resource constrained. People gave a few examples in this subtopic: https://news.ycombinator.com/item?id=14962684

People and programs change their minds all the time. A lot of behaviors we consider intuitive rely on some form of cancelation. People gave a few examples in this subtopic: https:/…

It would be race-free if `.then()` was invoked synchronously when evaluating the `await` expression, just like in normal Promise-based code. Currently in V8, there's a delay betwee…

Not familiar with cancelation tokens. Can you describe the approach?

Not good enough. Each ongoing request eats machine resources and counts towards the browser request limit (6 or so). Cancelation must release the underlying resources, which XMLHtt…

Yes. Depends on client bandwidth and CPU, but it's significant. In fact, it's insanely high. Not caring about "just another 100 KB" is how people end up with 2-5 MB bundles that ta…

I guess this needs a bigger answer. A well-designed tool should minimise the amount of states the program can be in. Asynchronous programming is already horrifically bad, it genera…

Glad you understand the problem. This is what futures are good for. Write an XMLHttpRequest adapter that returns a future, have an easy time composing or aborting operations.

Futures automatically coerce to promises, so yes. Even better, they come with generator-based coroutines that work with futures, and are automatically cancelable: https://github.co…

I believe we need a hierarchy of primitives: Level 0: one-value operations (promises = futures). Level 1: multi-value operations (streams = observables), implemented in terms of on…

Sort of answered above: https://news.ycombinator.com/item?id=14963152