Posted By: Charles | Sep 28th @ 8:50 AM | 40,593 Views | 31 Comments
Software Developer extraordinaire and language compiler geek Wes Dyer and programming language design guru and LINQ co-creator Erik Meijer dig into the Reactive Framework (Rx). This is part 2 of 2. See part 1 here.

Here, Erik and Wes continue their discussion on the core ideas behind Rx. Rx is deep (as in profound), as you must have gathered by now. Erik, of course, continues to keep the theoretical basis of all this squarely front and center so we understand the relationship between principles and practice.

Enjoy!
Rating:
6
0

If you are interested in hearing more about Rx make sure to attend my PDC (http://microsoftpdc.com/Sessions/VTL04) or my QCON (http://qconsf.com/sf2009/speaker/Erik+Meijer) talks.

 

 

This seems very exciting stuff.

 

Coming from the videogames industry I got fascinated by functional reactive programming, and started learning Haskell and FRP a couple of years ago.

 

C# is still my favorite language for writing production software, and it's great to see that my studies of Haskell & FRP will now help me write better reactive C# code. I did not expect this FRP hobby of mine to actually be useful in C#! So many thanks guys!

 

Now the FRP systems I looked at (Fran, Yampa, Fruit, Reactive) are side effect free; it will be interesting to see how easy it is to master Rx in the presence of side effects.

 

One thing that seems unclear to me is if Rx uses times at which events happen, and how they are sorted. For example, in Conal Elliott's Reactive library you have a merge function that merges two event streams, ordering them by occurrence time, left-biased if two events happen at exactly the same time.  Not sure how Rx handles that; I guess because it embraces side effects, it doesn't really care, since it is fully push based, what is pushed first is handled first?

 

Really looking forward to play with it!

I am trying to work out what advantages this has over classic tightly coupled event handling or asynchronous WCF service calls. The only thing I can think of is the merging of events via linq however, is this not achievable via a 'normal' messaging model such as msmq where by the queue is doing the merging of events/messages? An uglier example of this is having a session state aware WCF service. Am I missing the point and is this just another way of doing it with the advantage of being easier to implement so developers can concentrate on discovering the needs of a system rather implementing solutions to the problems the needs of the system produces?

 

Regarding the problem with receiving non linear events and solving this with the until, how does this work when the observers are in distributed system like a cloud environment where the until would need to be able to block/dispose of processes on other physical/virtual machines? Unless the cloud is already doing the thread merging and I just haven't found out yet.

WOW ... TKX Charles .... this was simple an amazing video to watch. And YES Erik Rx is both elegant and mathematically correct (just like LINQ) BUT PLEASEEEE do not retire. Wes Dyer dude u rock too bro ... and I am jealous u get to work with Erik Smiley

 

THANKS again Charles/Erik for putting togather the E2E series and allowing us, "the App Develpers" really learn more about language design and how stuff is actually implemented behind the scenes.

 

p.s.  I introduced these videos to my hard core Java developers and they are slowly but surely getting warmed up to the beauty of C# and .NET in general Smiley just love it.

Microsoft Communities