The iterable utilities would be geared towards *sync* iterators primarily, which are typically *not* used for I/O. They would have more in common with Lodash than RxJS.
And JS is not async-first - that's Go, Haskell (with GHC), Clojure (somewhat), and some mostly obscure and/or niche languages, which feature non-blocking I/O with deep language integration (you don't have to code explicit support for it) complete with easy parallelism and syntactic sugar for other things concurrency-related. JS is async-second, like C# and F#, which each feature native non-blocking and (in some cases) optional blocking I/O along with native syntax and/or DSLs with appropriate builtins to support the non-blocking variants, but you still have to code specially for them. Observables are typically used for *input*, not *output*, but they do actually shine well for what they do. They aren't IMHO the ideal abstraction, but they're pretty close for relatively procedural languages. (I prefer duplex streams as a primitive, not observables - they're usually more fault-tolerant, and they're easier to compose and integrate with.) One last thing: Koa now uses promises, not generators. They only used generators to emulate what async functions provided, and they first made the decision before the feature went stable in V8, even before the feature hit stage 4 in the spec. On Wed, Jul 11, 2018, 12:06 kai zhu <kaizhu...@gmail.com> wrote: > > The main things I know of that are blocked on the pipeline operator IIUC > > are observables and iterable utilities. > > unlike synchronous languages like python where everything blocks, do > we really want iterable utilities for a [one-of-a-kind] async-first > language like javascript? > > nothing good has ever come from mixing generators with async i/o from > my experience. it typically results in hard-to-reason > logical-nightmares (and hard-to-fix timeout bugs), that makes > web-project integration-work more hellish than it already is (think of > how un-debuggable most projects that use koajs-middlewares end up). > > -kai > > On 7/11/18, Isiah Meadows <isiahmead...@gmail.com> wrote: > > The main things I know of that are blocked on the pipeline operator IIUC > > are observables and iterable utilities. As-is, using observables without > > methods or a pipeline operator starts to feel like you're using Lisp, not > > JS, because of the sheer number of operators. (It's an array over *time*, > > not *space*, so you have things like debouncing, throttling, etc. that > you > > have to address.) Iterables are in a similar situation because they're > > lazy, it's protocol-based rather than prototype-based, and JS lacks > > anything like monads. > > > > ----- > > > > Isiah Meadows > > m...@isiahmeadows.com > > www.isiahmeadows.com > > > > On Tue, Jul 10, 2018 at 11:18 AM, Ben Wiley <therealbenwi...@gmail.com> > > wrote: > > > >> It’s not clear to me that pursuit of new Array methods should be > >> abandoned > >> purely on speculation that the pipe operator will pass Stage 1. > >> > >> > >> > >> That said, the realization that Object.assign provides this > functionality > >> is enough for me to quit pursuing (my version of) > >> Array.prototype.replace. > >> > >> > >> > >> I’d prefer that further discussion concern the earlier-discussed > >> extension > >> to the Array rest spread syntax. :) > >> > >> > >> > >> Ben > >> > >> > >> > >> *From: *Andrea Giammarchi <andrea.giammar...@gmail.com> > >> *Date: *Tuesday, July 10, 2018 at 10:50 AM > >> *To: *"T.J. Crowder" <tj.crow...@farsightsoftware.com> > >> *Cc: *"therealbenwi...@gmail.com" <therealbenwi...@gmail.com>, " > >> es-discuss@mozilla.org" <es-discuss@mozilla.org> > >> *Subject: *Re: Array.prototype.replace > >> > >> > >> > >> just a few days ago another full stack JS dev mentioned Array replace > and > >> it has nothing to do with what was proposed in here: > >> > >> https://medium.com/@gajus/the-case-for-array-replace-cd9330707243 > >> > >> > >> > >> My TL;DR response was that once the pipe operator is in, everyone can > >> bring in its own meaning for `array |> replace` and call it a day. > >> > >> > >> > >> Keep polluting the already most polluted prototype of them all doesn't > >> look like a good strategy to improve the language. > >> > >> > >> > >> Just my 2 cents. > >> > >> > >> > >> > >> > >> > >> > >> On Tue, Jul 10, 2018 at 3:37 PM T.J. Crowder < > >> tj.crow...@farsightsoftware.com> wrote: > >> > >> On Tue, Jul 10, 2018 at 2:18 PM, Ben Wiley <therealbenwi...@gmail.com> > >> wrote: > >> > Hm, despite the fewer number of points in the cons category I'm > >> persuaded by > >> > the argument that we don't want people getting arrays and objects > >> confused. > >> > Might be best to limit that until there is a compelling use case which > >> there > >> > might not be. > >> > >> Heh, whereas despite having written that first bullet in the footgun > >> column somewhat forcefully (looking back), I go the other way. :-) > >> > >> > >> > >> -- T.J. Crowder > >> > >> _______________________________________________ > >> es-discuss mailing list > >> es-discuss@mozilla.org > >> https://mail.mozilla.org/listinfo/es-discuss > >> > >> > >> _______________________________________________ > >> es-discuss mailing list > >> es-discuss@mozilla.org > >> https://mail.mozilla.org/listinfo/es-discuss > >> > >> > > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
