Mitranim

10 ms·

1.
by Mitranim 9y ago
Added more examples and motivations for cancelation: https://github.com/Mitranim/posterus/blob/17c89694ecdce4633f...
2.
by Mitranim 9y ago
Added a readme section on Rx: https://github.com/Mitranim/posterus/blob/17c89694ecdce4633f...
3.
by Mitranim 9y ago
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 key to simplicity and correctness of
4.
by Mitranim 9y ago
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.js callbacks. They can also return new futures, transfor
5.
by Mitranim 9y ago
Glad it works for you! Kind of answered in another subthread: https://news.ycombinator.com/item?id=14963524
6.
by Mitranim 9y ago
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 explicitly avoided this in Posterus, sticking with exclusiv
7.
by Mitranim 9y ago
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 again. Bundle size: a typical SPA imports multiple librar
8.
by Mitranim 9y ago
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 operation competing against timeout). The purpose of promises&
9.
by Mitranim 9y ago
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 perspective of a language designer. You want to
10.
by Mitranim 9y ago
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!
11.
by Mitranim 9y ago
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 Node.js.
12.
by Mitranim 9y ago
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?
13.
by Mitranim 9y ago
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 primitives that let you manage resources properly
14.
by Mitranim 9y ago
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 destructor interface, we could have automatic resource management.
15.
by Mitranim 9y ago
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
16.
by Mitranim 9y ago
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://news.ycombinator.com/item?id=14962684
17.
by Mitranim 9y ago
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 between evaluating `await` and actually calling `.then()`. If
18.
by Mitranim 9y ago
Not familiar with cancelation tokens. Can you describe the approach?
19.
by Mitranim 9y ago
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 XMLHttpRequest allows you to do. By being promise-based, fetch is
20.
by Mitranim 9y ago
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 take seconds to download on weak networks
21.
by Mitranim 9y ago
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 generates combinatorial explosions of intermediary states. Adding
22.
by Mitranim 9y ago
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.
23.
by Mitranim 9y ago
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.com/Mitranim/posterus#routine You can ev
24.
by Mitranim 9y ago
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 one-value operations. Tokio did it well for Rust ( https:&#x2F
25.
by Mitranim 9y ago
Sort of answered above: https://news.ycombinator.com/item?id=14963152
26.
by Mitranim 9y ago
In my experience, most async operations fit very well within the small feature set of promises/futures, with only a few operators (map/all/race). Streams should be the optional next layer of abstraction, not the only layer of
27.
by Mitranim 9y ago
Here's some examples from my experience. * Server. Request handler starts expensive work. Let's say 4-5 database requests, some FS operations, rendering and sending response. Client disconnects. Running those operations will waste
28.
by Mitranim 9y ago
Good suggestion, should probably address this in the readme. Short answer: observables do too much, and Rx is WAY, WAAAAY too large. We need simple async primitives before layering bigger abstractions on them. They shouldn't take encyc
29.
by Mitranim 9y ago
We're not competing with VMs here. From what I hear, like many other built-ins, "native" promises in every VM are implemented in JavaScript. They're not always well done (V8 promises were really bad for a while), and pay
30.
by Mitranim 9y ago
Pretty much what jrs95 said. If I understand the question correctly, `Future.all` and `Future.race` address exactly this case. [1] https://github.com/Mitranim/posterus#futureallvalues [2] https://github.com&

More ›