Going Deep

Bart De Smet: Rx v2.0 Release Candidate - Time, Error Handling, Event Subscription

Download this episode

Download Video


Bart De Smet is back and he's going to go deep into improvements made to Rx 2.0 RC (so, Rx 2.0 getting close to coming out of the oven!). As you'd expect, Bart and company have been very busy since Rx 2.0 Beta - lots of performance and reliability improvements and some heavy work in how Rx manages time, new error handling capabilities and event subscription improvements for Rx running on WinRT.

Most of the time is spent at the whiteboard - very comfortable and natural place for Bart!  

Note: there is a lot of time in this interview, both in terms of interview length and the notion of time itself. Use at your own risk and watch out for unexpected wormholes.

More on Rx 2.0 RC:

This new release of Rx includes a number of improvements to the way we deal with time. As you likely know, dealing with time is a complex undertaking in general, especially when computers are involved. Rx has a lot of temporal query operators to perform event processing, and therefore it needs to be able to schedule work to happen at particular times. As a result, notions of time exist in virtually any layer of the system: from the schedulers at the bottom (in System.Reactive.Core) to the query operators at the top (in System.Reactive.Linq). [Bart De Smet]



Available formats for this video:

Actual format may change based on video formats available and browser capability.

    The Discussion

    • exoteric

      Ah, .NET 4.0.

      I've just incorporated Rx 1 in a solution because we needed .NET 4.0 and just couldn't rely on .NET 4.5 yet, so this is very welcome.

      The current F# Rx streaming pipeline abstraction that we use looks like this:

      type 'a Signal=
          | ValueSignal of 'a
          | ErrorSignal of Exception
          | StatusSignal of string
          | ProgressSignal of decimal

      type 'a Process = 'a Signal IObservable
      Anxious to see how well Rx works in practice in our solution but so far the subscription model provides some design elegance where we can have logging and statistics be separate concerns: we can just subcribe to processes (which are "Rx signals") and do statistics or log errors. And the GUI and cmd line has a uniformly shaped event stream to consume.
    • Maddus Mattus


      I absolutely love Rx, I think it's the missing LINQ (hehe) in programming today. And people say Microsoft doesnt innovate Wink

      In a previous thread I asked why all events could not be replaced with observables, as events are an obvious hack Smiley, Bart stated that it would be too expensive because per event we would have an instance of an observable. Loading the .Net framework into memory would then hog too much memory.

      I've come up with what I think is a solution.

      When currently you raise an event, you create an OnSomeEvent method, wich checks if the actual event is not null and then raises the event. We can do something simular with Rx. Create an private Subject<T> expose it as an property of the type IObservable<T> with only a getter. In the getter do lazy activation if the subject is null. In the OnSomeEvent check if the subject is not null and call an OnNext.

      I'm still strugling with time based operations myself. In my PullToRefresh panel, I need some timeout wich is cancellable. I solved it using pattern recognition, but I think a more elegant solution is out there. So can't wait to see what improvements this release has.

      Thanks for this Bart, your poster is going above my bed (if my wife let's me)!

      Edit; lol @ Atomium on your desk Wink

    • felix9

      Hmm.... if you feel B8 blog posts are way too long, you are not using Rx. Devil

    • Maddus Mattus

      @felix9: It still boggles my brain on how complicated something as simple as reactive programming can get.

      I have to think, code, rethink, code, rethink, code, test, rethink, code, just to get the simplest scenario's to work. I feel I'm missing something, some trick, some common approach, maybe some more XML comments on the Rx Extensions methods would be helpfull.

      It feels like you have to know Rx inside out to just get started with it, to me that is shamefull because I believe it's one of the most important discoveries of our time (yes, I really really mean that).

    • bdesmet

      @Maddus Mattus: The XML comments have been improved signficantly in RC, and we're working on improving the docs in general by RTM.

    • Maddus Mattus

      @bdesmet: awesome! Cant wait to get cracking!


    • David Hanson

      Great video. Temporal stuff always fries my brain. Love seeing how much thought has gone into this great set of extensions.

    • Charles

      BTW, Bart will be appearing on C9 Live at TechEd on 27 June. Please queue up lots of meaty Rx questions! Smiley


    • Alex

      Hi, I just found out about RX and learned to love it immediately in my first project with it. Is there any documentation out there explaining all the methods?

      Looking forward to 2.0 :)

    • Charles
    • exoteric

      Is the Rx team also playing with Rx in F#? I've started to use this:


      The nice thing about F# is that you can implement syntax for Rx.

      Although I don't quite like that the For and While builder methods use IEnumerable (seq). Because then you end up converting IObservable's to IEnumerable's and then returning new IObservables again.

      Maybe you guys have some best practice here as well...


    • LeeCampbell

      @Maddus, I think there is still a cost of making all events (just a multicast delegate) into subjects (classes with state and behaviour). In your own project you can easily favor IObservable instead of events, and I agree that 90% of the time, they are much better.

      @Maddus, @Felix, @Alex, I too thought there was a little bit of content lacking on Rx. The Videos are awesome, but searching blog posts, video etc can be hard work. So, I bit the bullet and wrote the book on it. It is free, check it out @ www.IntroToRx.com. I am still waiting on the eBook generators to give us a good output before we can publish to Kindle etc., but all the content is right there on the site. -@Charles, feel free to plug the book dude, share the love Wink

    • Maddus Mattus

      @LeeCampbell: A W E S O M E

      I think there is still a cost of making all events (just a multicast delegate) into subjects (classes with state and behaviour).

      I know it's impossible at v4.5 of the .Net framework, but one can still dream right?

      And the subjects would be lazy instantiated, so if they are not used, they are not allocated.

    • aL3891

      Awsome stuff Smiley

      Also, i'd like to say that the reason i keep asking about bcl is that i think Rx is a really foundational technology that nearly all apps can use in some form.. Also, i think it would be really great if the rest of the framework could use Rx to a greater extent, exposing observables in more places.

      I really think Rx should have language support.. A completley non breaking [i think] way to do it would be to allow any event to be treated as an observable directly. The FromEvent methods are great but the they still provide a slightly higher usage bar than what's optimal imo.

      So im not trolling, i just think rx is to awsome to leave out of the framwork Smiley

    • Maddus Mattus

      @aL3891: events out, rx in Wink

    • aL3891

      @Maddus Mattus:

      ideally, yeah Smiley raising events is also a pain, especially if it supposed to be thread safe.. checking if the event is null? whats up with that..

    • bdesmet

      @Maddus Mattus: No need for extremism here Smiley. Just like methods can be turned into first class objects using delegates, events can be turned into first class objects using observable sequences.

      The analogy extends to a comparison of advantages and disadvantages between both approaches. For example, objects have a cost that may not be warranted for a lot of simple events (e.g. button clicks). Also, events are well-suited for a code-centric usage (e.g. kicking off a simple action), while observable sequences provide for a data-centric approach (e.g. computing statistics over temporal data).

    • Maddus Mattus

      @bdesmet: My world is a bit extreme, it's either 1 or 0 Wink

      It still amazes me that a lot of people havent heard about Rx, I continue to teach the developers around me the phylosophy of Rx.

      And it's so much more then a abstraction layer over events. You can project it to larger systems aswell. Like SharePoint for instance, all it does is pull, there is not much push going on.

      Facebook is more push then pull, that's why I think they are so popular. You get pulled into the thing!


    • Thorium

      So... I'm using Silverlight (and Rx 1.0) and have this kind of code:

      IO<Result> res1 = GetWebserviceRequest();// (or/and FromEventPattern);
      var res2 = res1.MuchLinqHere();
      var res3 = res2.ObserveOnDispatcher();
      var res4 = res3.LessLinqHere();
      var d = res4.Subscribe { ... };

      The great thing about Rx is that it is much more efficient than normal events: "MuchLinqHere()" don't cause load to the UI thread. I'm happy with that.

      "LessLinqHere()" will cause load to UI thread as it is executed there, right? So... In this application there is a lot of code. I try to call ObserveOnDispatcher as late as possible.

      It has to be called before the code tries to make a side effect in Linq: e.g. access Application.Current... or UI.

      Now, are you saying in the video that in Rx2.0:

      1. The ObserveOnDispatcher() will happen automatically before "MuchLinqHere()"? Will I lose performance? 
      2. Or will it be called just before Subscribe? (Then will it still throw if there are side effects in Linq?)
    • bdesmet

      @Thorium: The only new implicit thing for FromEvent* usage is an implicit SubscribeOn based on the SynchronizationContext.Current captured at the point of query construction. In other words, only the side-effects of subscribing (+= on the event) and disposing the subscription (-= on the event) are marshaled to the right context, in order to avoid issues for thread-affine events (e.g. in Windows XAML for Metro Style apps). There's no implicit ObserveOn behavior, hence all existing guidance to insert this explicitly stays the same.

      Long story short: you don't have to change any of your code.

    • Thorium

      Ok, thanks!  Big Smile

    • hhvdblom

      Was looking for the documentation of rx 2.0. You have to install the package for it? Was wondering if the ForkJoin function was extended so that it will be possible to return different value types. Now I made my own for WP7 with some help of sample data.

    • Subito

      It still amazes me that a lot of people havent heard about Rx, I continue to teach the developers around me the phylosophy of Rx.

      And it's so much more then a abstraction layer over events. You can project it to larger systems aswell. Like SharePoint for instance, all it does is pull, there is not much push going on.

      Facebook is more push then pull, that's why I think they are so popular. You get pulled into the thing! http://www.annunci-subito.it

    Comments closed

    Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.