Going Deep

Bart De Smet: Rx 2.0 RTM and RTW

Download this episode

Download Video


Rx 2.0 is RTW! Get it here.

I caught up with Bart at his whiteboard (of course) to discuss the significance of this release as well address some of the great additions to Rx as outlined below (many of the topics below have been discussed in depth in other Rx interviews with Bart.) We also talk about the new experimental build shipping model. Much of the time is spent talking about the portable libraries architecture for Rx for Windows 8, .NET 4.5, WP7/7.5 and beyond. Bart has been very, very busy and as usual his engineering is golden.

Tune in! It's always a pleasure to geek out with Bart. So much to learn. Congratulations to the Rx team!!!

The highlights of Rx 2.0 include:

  • Support for building Windows Store apps for Windows 8. This includes primitives to synchronize with the Windows XAML CoreDispatcher and interop with WinRT events and IAsync* objects.
  • Support for Portable Class Library projects, allowing code reuse across ".NET Framework 4.5" and ".NET Framework 4.5 for Windows Store apps" projects. We're planning on adding Windows Phone 8 support to this going forward.
  • Integration with the new C# 5.0 and VB 11 "async" and "await" features. In Rx v2.0, you can await an observable sequence, allowing one to apply the power of Rx to the new asynchronous programming model.
  • Enormous performance improvements, with a 4x speedup of the query pipeline, vastly reduced object allocation rates, massively increased throughput of schedulers, and much more.
  • An improved error handling strategy, enabling higher resiliency and proper resource cleanup for queries in the face of user errors at various levels.
  • Thorough revisit of the way we deal with time, to improve efficiency and predictability. This includes better support for periodic timers, improvements to absolute time scheduling, etc.
  • Various new and improved query operators.



Available formats for this video:

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

    The Discussion

    • White African

      And to think that I was just praying for Rx to be released with Windows 8 Big Smile Rx is hands down one of the most revolutionary frameworks I have ever seen. Love it Smiley

    • Imgen

      What is the provider Bart mentioned around 15:00?

    • PeteGoo

      Hi Imgen, it's Pushqa, something I created in my spare time a few months back. I'm currently working on updating it to current bits and improving some of the use-cases and samples. 



    • n0x30n

      Is it just me or is the "High Quality WMV" video out of sync?

    • Minh

      I would love to hear "So, what is RX?" at the top of the interview... :-(

    • Richard.Hein

      , PeteGoo wrote

      Hi Imgen, it's Pushqa, something I created in my spare time a few months back. I'm currently working on updating it to current bits and improving some of the use-cases and samples. 



      Yes, finally an IQbservable implementation besides the WMI example, very good work Pete ... I was wondering about the name as well, because it is unclear ... I thought maybe it was PushQ(bserv)A(ble)?   

      Gratz to the Rx team for the release; keep the LINQ to Everything dream alive!

    • Charles
    • Charles

      @n0x30n: Fixing now. Weird.


    • exoteric


      I'm also using Rx in an application for subscribing to status and progress updates and for error logging for "processes" (Rx streams of "signals")
      Statical Supervision

      Now to watch the video and then later update to Rx RTM.


    • PeteGoo

      @Richard.Hein:Hehe, the name doesn't have any real hidden meaning. I knew I wanted to promote the PUSH messaging application and the Queryable aspect, I guess I added the "A" to make it sound kiwi/Canadian Smiley

    • n0x30n

      @Charles: Thanks. Redownloading ...

    • Charles

      @n0x30n: Let me know if it's better. Sorry about that.


    • dcuccia

      Thanks to Bart and Charles for yet another excellent Rx video. Here's a thought and question for you guys:

      I could be reading this wrong, but it seems to me that if the Rx team has a hard time creating portable libraries (e.g. last-minute change in binary deployment/partitioning strategy between RC and RTM), the rest of us are probably going to do it wrong every time. I lead a small OSS .NET library project, and it's pretty intimidating to come up with a plan for deploying device-specialized libraries that themselves depend on platform-specific BCL classes, not to mention the collisions Bart mentions between portable and non-portable binaries.

      This "platform enlightenment" and versioning stuff seems to be emerging as a pattern in itself - a virtual requirement of the new level of platform fragmentation in .NET. What's the hope that we can get tooling, or at least guidance, to help other library devs out there on this topic? I presume the platform specialization and discovery process would be implemented with something like MEF. Can you share the bootstrapper process for this? Can we expect IJW-like behavior in a future major .NET version?

      Thanks in advance for any help or guidance.


    • bdesmet

      @dcuccia: In fact, the hardest part was working with a moving target, i.e. .NET Framework 4.5 Beta, RC, and internal interim builds, while developing Rx v2.0. If we'd only start now, with the final bits of .NET 4.5 and Portable Library support, it wouldn't be as hard.

      The main thing to decide is what you want to do with platform-specific functionality that ended up in a bottom layer of your library: keep the API surface there, discover it at runtime, and mark it deprecated to stimulate new usage patterns; or have a clean slate release for Portable Library with migration guidance for the types/members that moves. (In fact, if you don't have to slice a type because it had both platform neutral and platform-specific stuff in it, you can simply move the type up the layer map.) As explained, we went with the second approach initially, but the benefits diminished as we went along, simply because Portable Library's intersection between our target platforms got much better by RTM.

      If I'd be doing it again now, I'd really strive for a portable core that eliminates platform-specific copies right from the start. Based on what falls out of the intersection, I'd decide whether some kind of enlightenment mechanism is required / warranted or not.

      To implement such an enlightenment mechanism, the main trick is Type.GetType(string, bool) to look for a known type in a known assembly (ideally demanding an exact version match, saving you from future headaches) implementing a known interface. Then decide whether you can do a graceful fallback if the module is missing. At the same time, try making all deployment vehicles such that the enlightenment assembly is always installed (e.g. as part of a NuGet package, or in an Extension SDK).

      I'll chat with the Portable Library team about documentation and guidance plans.

      Hope this helps,

    • n0x30n

      @Charles: It's perfect now. Thanks for fixing it so quickly.

      Also thanks to the Rx team for the awesome work they are putting into Rx.

    • LeeCampbell

      @Minh You can also get the zero-to-hero guidance from www.IntroToRx.com. If it doesn't provide what you need then (as you sound like the target audience) then we will try harder for version 2 of the book/site, if you provide the feedback.

    • dcuccia

      @bdesmet: Thanks very much for the reply and helpful suggestions! Will definitely keep an eye out for any official guidance, too. 

    • Baron

      Congrat Bart de smet for your great work!! Hoppe to see you in Feb at TechEd Africa..

    • barongnt

      @bdesmet any link between Rx and SignalR ?

    • dcuccia
    • Herman van der Blom

      I am waiting for the RTM of the Windows Phone 8 SDK. I heard its under embargo until September 7th. Is version RX2 in that SDK? I used a ForkJoin in RX1, used 3 async calls in that, projected those results in 3 object types, because the results must be of the same type, after receiving the complete result of the 3 calls, I converted those object results back to the types I needed. How is that implemented in RX2?, the same as in RX1?

    • bdesmet

      @Herman van der Blom: Rx v2.0 won't be part of the Windows Phone 8 SDK, but the existing Microsoft.Phone.Reactive will still be supported in order for users of WP7 to migrate to WP8. We will release an Rx v2.0 build with Windows Phone 8 support though, also based on Portable Library to allow sharing between .NET 4.5, .NET 4.5 for Windows Store apps, and Windows Phone 8.

      In order to use ForkJoin, you'll have to add a reference to the experimental Rx assembly, but it should continue to work as it did before. Alternatively, if this is single-value async, you could also use Task.WaitAll or Observable.CombineLatest to achieve a similar effect, without having to rely on the experimental functionality.

    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.