3 ms·
There's also a lot of similarity with Rx.JS and observable based (aka "Reactor") patterns: Rx.Observable.fromTime().subscribe(tick) Rx.Observable.from
by e0m 10y ago
There's also a lot of similarity with Rx.JS and observable based (aka "Reactor") patterns:
Rx.Observable.fromTime().subscribe(tick)
Rx.Observable.fromSocket(mySocket).subscribe(handleEvent)
https://github.com/Reactive-Extensions/RxJS https://github.com/Reactive-Extensions/RxJS
Regardless of the exact library or pattern, the broader concept of treating data sources as asynchronous event streams you can subscribe and react to definitely simplifies data flow and makes systems very robust.
An additional benefit of this pattern is the natural way it makes it easy to filter, chain, map, etc onto these subscriptions. Once again from the Rx world, http://rxmarbles.com/ http://rxmarbles.com/ does a great job visualizing these patterns.
- WorldMaker 10y agoI think that's my biggest question reading the article here: Has Elm been ignoring the work going on with Rx all this time? These Elm subscriptions sound like "half" of Rx, and from what I can is still 'missing' thus far some of the "higher order" Observable tools such as filter, chain, map, throttle, et al.
- iheartmemcache 10y agoAfter reading the article, I went into their IRC chan to post this question (i.e. are they leveraging all the research from really-smart(TM) PhD's at Microsoft Research & production testing that Rx has behind it). This guy has a doctorate, so I'd imagine there was a reason why RxJS wasn't leveraged, especially since it seems like a natural fit especially with Typed.*. And n general the Elm/Haskell community is way less fan-boi-trendy-node-js-macbooks-Rails-flavor-of-the-wheel guys who will nay-nay anything that is Microsoft. I'd love to make the Elm jump, but it still has the Haskell stigma (not enough engineers making hiring difficult, too 'academic', etc) where my clients (enterprise) won't let me dev with it. They do however let F# in some projects. MS should do what they did for OCaml -> F#, but for Elm -> something_I_can_say_is_first_party_MS_supported.
- sotojuan 10y ago> And n general the Elm/Haskell community is way less fan-boi-trendy-node-js-macbooks-Rails-flavor-of-the-wheel guys who will nay-nay anything that is Microsoft. This really hasn't been the case for RxJS at all. It's been praised and version 5 is largely a community effort rather than just an MS effort. You got Ben Lesh and Andre Staltz putting in the most work and neither are MS. The only thing from MS people don't seem to give a chance is .NET. Everything recent (VS Code, open sourcing stuff, Chakra engine, etc) has been met positively and not dismissed.
- WorldMaker 10y agoI feel some of this. I almost had a Microsoft-first shop let me use Haskell when I pointed out how many of Haskell's lead developers worked at Microsoft Research UK. As for the Microsoft "first party" F# equivalent for the web, that would be Typescript. Typescript's typing isn't yet to the rigor of OCaml, much less Haskell or Elm, but it's getting better every release.
- weq 10y agoI learnt Haskell at uni in 2000. Now im a c# guy mostly unless im in the broswer. You know u can program in pretty much the same way using C# as u can haskell? I dont see the attraction of going to F#, but thats because i need to consider maintaince costs of the code-base as well as them both compiling down to IL. Functional langauges are great, dont get me wrong, if i had the choice id probably give 'elixir' a 'rust' ;) but i make do with my existing c# knowledge, sprinkle in some Rx, isolate my side-effects in closures when pure functions cant be had, and im pretty happy with both the look, readability and maintance burden my code generates. The advantage of C# here over a first order functional lanuage is my ability to customise the syntax to make things self-documenting as well.
- wheatBread 10y agoDefinitely not ignoring. I talk about the relation between Elm and that sort of stuff in https://youtu.be/Agu6jipKfYw https://youtu.be/Agu6jipKfYw Lots of things look similar in this area that are not. I also offer an analysis of "higher order" observables in https://youtu.be/DfLvDFxcAIA https://youtu.be/DfLvDFxcAIA, and the big difference is the underlying thread architecture you get using these two. I hope I'll be able to make these sorts of things clearer in time!
- weq 10y agoExactly. Rx was created by MS research for Azure -- mostly to abstract away the threading model in the cloud - why reinvent the wheel when Observable / Rx is built for every platform you use and is fantastic. When ELM came along with its signals, im like, meh, why not Rx? Im not even going to bother to learn it, your at v0.1 and ur gonna see why u need it soon enough. Subcritiption? Dont reinvent the wheel like Redux? Why not Rx? A few months later, everyone is going "how we we handle async actions properly?" Well thats an Observable my dear friend! Just like when Flux "came out". They just rebranded Event Sourcing in the client UI. Im getting pretty fed up with all this mumbo jumbo. I write C# mostly, i like FRP, ES, unidirectional flows. Im going to bring a slim universal c# solution with a typescript/JS bridge to the OSS community. The main philosphy is, one client/server architecture, to build scable responsive apps. With builtin backpressure handling. If ppl had just embraced Rx like 6years ago when it was first V1'd, imagine how much further along the road we would be now? Like seriously, get over urself OSS fanboys, just cause its MS, doesnt mean its bad.
- Paradigma11 10y ago/agree.