Ben Lesh

More questions on the Promise-returning methods: 1. For `find()`, if the value is not found, should the returned promise reject? RxJS would reject in this case, because if you have...

Weird... That diff was gnarly. I just redid the changes on top of master.

Definite plans? Not from me, because I'm not really in a position. But I'd have asks. Chrome did ship `console.createTask` recently, which is interesting and perhaps useful for debugging things...

This is still pretty primitive without the Observable constructor though. With the constructor there are a lot more robust possibilities (because it can setup and teardown the socket)

FWIW, in RxJS, `takeUntil` will accept anything that `Observable.from` would accept. So a promise would totally work, and that's a fairly common usage.

One of the things that was discussed at TPAC was the issues around doing this: ```ts observable.find(() => true).then(([e]) => { e.stopPropagation(); // OOPS! Too late because promise scheduling :(...

I'm sorry if I missed this, because it's a big thread. There's really three ways I see people buffer async things: 1. Buffering a specific number of things (common) 2....

RxJS (and other observable implementations) implement `forEach` to take a callback and return a `Promise` when it's done. > I definitely don't want to add a "concurrency" parameter I would...

IMHO, It should be done in sequence as a matter of practicality. In my experience with RxJS, in-sequence async is a lot easier for people to reason about than parallel...

Parameterized concurrency could be done in a follow up as well. FWIW, RxJS's parameterized concurrency is very rarely used. I know that's anecdotal, but it's a pretty big anecdote.