3 ms·

> The error occurred after u2, but the errors thread got descheduled and the userActions thread kept on processing. Your suggested case is contrived and doesn'

by staltz 11y ago

> The error occurred after u2, but the errors thread got descheduled and the userActions thread kept on processing. Your suggested case is contrived and doesn't apply to JavaScript (the examples were in JavaScript where I assume all these streams are in the same thread). I am not claiming withLatestFrom is the correct mechanism for determining order of events in multi-threaded assumptions. That's an orthogonal concern to the issue at hand. > I strongly suspect that combining async streams will prove to be a problem in practice Combining async results is a true problem and people often attempt to solve them with callbacks or heavy usage of Futures/Promises. Rx solves these problems easily, and I've witnessed a lot of developers confirm this when learning Rx. It's not hard to teach the difference between withLatestFrom and combineLatest and their intended use cases. Much easier than managing callback hell, which is what RxJS intends to replace.

fmstephe 11y ago
(A great thing about HN is getting to talk with the authors directly) I didn't recognise that you were talking chiefly about javascript. It is true that my example doesn't apply here. Ok, then I would make one comment (and edit my first comment). I would avoid the discussion of simultaneity at the start 'Events in parentheses happen “simultaneously”. In practice they happen at slightly different times, but separated by only a couple of nanoseconds, so people understand them to be simultaneous. Events (c1c2) are called glitches and sometimes considered a problem because one would expect only c2 to happen.' Because you are working in a single threaded simultaneous events just don't exist. The glitches you describe occur completely independently of timing, nanoseconds or otherwise. Drawing up diagrams where events occur at the same time is adding complexity which doesn't exist. errors ---e1-------e2--------------- userActions -u1------u2------------u3---- analyticsMessages ---e1u1--(e1u2 e2u2)---e2u3-- errors ---e1----e2------------------ userActions -u1----------u2--------u3---- analyticsMessages ---e1u1--(e2u1 e2u2)---e2u3-- Both of these scenarios produce glitches (as I understand it). So we don't need any notion of 'simultaneous events' to create them. Anyway - that is nitpicking. I enjoyed your article. I agree that the scenario described at top does not apply in javascript. I too strongly dislike callbacks :)

by staltz 11y ago

fmstephe 11y ago

(A great thing about HN is getting to talk with the authors directly) I didn't recognise that you were talking chiefly about javascript. It is true that my example doesn't apply here. Ok, then I would make one comment (and edit my first comment). I would avoid the discussion of simultaneity at the start 'Events in parentheses happen “simultaneously”. In practice they happen at slightly different times, but separated by only a couple of nanoseconds, so people understand them to be simultaneous. Events (c1c2) are called glitches and sometimes considered a problem because one would expect only c2 to happen.' Because you are working in a single threaded simultaneous events just don't exist. The glitches you describe occur completely independently of timing, nanoseconds or otherwise. Drawing up diagrams where events occur at the same time is adding complexity which doesn't exist. errors ---e1-------e2--------------- userActions -u1------u2------------u3---- analyticsMessages ---e1u1--(e1u2 e2u2)---e2u3-- errors ---e1----e2------------------ userActions -u1----------u2--------u3---- analyticsMessages ---e1u1--(e2u1 e2u2)---e2u3-- Both of these scenarios produce glitches (as I understand it). So we don't need any notion of 'simultaneous events' to create them. Anyway - that is nitpicking. I enjoyed your article. I agree that the scenario described at top does not apply in javascript. I too strongly dislike callbacks :)