Text transcript of show #198. February 3, Reactive Extensions for.net (Rx) with Erik Meijer

Transcription

1 Hanselminutes is a weekly audio talk show with noted web developer and technologist Scott Hanselman and hosted by Carl Franklin. Scott discusses utilities and tools, gives practical how-to advice, and discusses ASP.NET or Windows issues and workarounds. Text transcript of show #198 Reactive Extensions for.net (Rx) with Erik Meijer Scott sits down with Erik Meijer from the Cloud Programmability Team to hear about the Reactive Extensions for.net (Rx). Rx is a library for composing asynchronous and event-based programs using observable collections. Sound boring? Not even a little. Rx is a prescription for awesome. (Transcription services provided by PWOP Productions) Our Sponsors Copyright PWOP Productions Inc. Page 1 of 10

2 Lawrence Ryan: From hanselminutes.com, it's Hanselminutes, a weekly discussion with web developer and technologist, Scott Hanselman. This is Lawrence Ryan, announcing show #198, recorded live Thursday, January 14, Support for Hanselminutes is provided by Telerik RadControls, the most comprehensive suite of components for Windows Forms and ASP.NET web applications, online at In this episode, Scott talks about the reactive framework and link to events with Erik Meijer. Hi, this is Scott Hanselman and this is another episode of Hanselminutes and I'm here on the Microsoft campus in Redmond, Washington in Building 35 and I have the distinct pleasure of sitting down today with Erik Meijer. How are you, sir? I'm very good, thank you. We're sitting here in Building 35 in the Cloud Programmability group, is that correct? My team is called the Cloud Programmability Team and we're focusing on making it, you know, another way I say it is like democratizing the Cloud. Democratizing the Cloud. Well, you have a lot of black squares that are actually stacked up on your wall here. Are these all patent cubes. That's correct. So yeah, that's one of my hobbies, to collect patents, to write patents. Before I came to Microsoft I was a professor and as a professor you write research papers and so now when I came to Microsoft, in a product team you don't write research papers so I kind of substituted that with patents. Well, it's ever so imposing to notice that you basically use them as wallpaper. window here. Yeah. So I think yeah. My goal is to fill the whole You've definitely made your point. One of the things that I wanted to come and talk to you about is this notion of the Reactive Framework. I've heard people refer to it colloquially as things like LINQ to Events. But I want to start at the beginning because I think that the listeners understand LINQ to Objects. I think most of our listeners understand the basics of IEnumerable, but if you wouldn't mind talking to me like I'm a 4-year-old C# or VB programmer and then let's move our way up to programming the Cloud. Okay, no problem. So yeah, everybody is familiar with LINQ to Objects, that's kind of workhorse of the.net Framework and if you look at IEnumerable it is an interface that many collections implements. Uh-hmm. And so for example Arrays, Lists, Hashtable, they all implement the IEnumerable interface. The IEnumerable interface is a full interface so if you have a collection that implements IEnumerable, let's call that the producer, then the consumer asks the producer to get the next element. So you say "Move Next," or first you say Get Enumerator... Which gives you a handle to enumerate the elements of the collection, and then whenever you want to have the next element you say Move Next which causes the producer to create or produce the next element but as the consumer you're blocked. So you're pulling but you're blocked until the producer hands you the next element. And then once Move Next read those through, then the value is available and current. Does that mean that as someone who might implement that interface I could write a poorly behaved implementation of IEnumerable such that I'm blocking all callers or at least making them slow? For example, when you use iterators, the things that have yield to return so you might write something that returns an IEnumerable of Int where you never reach the yield return or it might take, you know, you do a thread.sleep of an hour. That means that now the producer is dependent on the collaboration of the producer to get those values. Well, I think that as the programmer, the consumer of those values has an assumption just like there are assumptions at the method and property level. When I call a method I expect it will take a little while. When I call a property, while it's possible that underneath the Get is a lot of evil and I'll sleep for an hour. There's an implicit contract that methods take time and properties don't Page 2 of 10

3 and I think that amongst those that produce, to me that consume, a foreach loop that this is going to be pretty fast. But let me give you an example of like in.net 4.0 when you read files or directory, that's not resurgent IEnumerable of files or... File info, yeah. File info, yes. But depending on your disk speed and so on, that might take a long time. So really there's a lot of latency in that call and so instead of blocking and instead of like pulling the data from the producer, you might be better of to be notified whenever the producer has a value available. Ah. And that kind of push model is something that we're all familiar about as well because if you write a UI application you're not asking a button "Give me your next click," but when the button has a next click it will call you back. push model. Exactly. So the button has a kind of But I think that the perception in the past is that that's slow. That events by their nature are slow and that maybe just apocryphal may just be perception. But that sense of if I ask you I want it now, if I count on you to tell me it's going to take a while for that message to get back so I think that people would intuitively and perhaps wrongly think that that kind of a model would be slow. I think that's not really relevant because whether it's slow or fast it's really a way to decouple the speed from the producer and the speed of the consumer. With Enumerable, I as the consumer now depend on the speed of the producer so I cannot proceed until the producer proceeds first. With the push model, with events I can do stuff while somebody else presses the button. I'm not blocked on that and this is the same why when you're doing, say in Silverlight, when you're making service calls, you know, you make the call and you get an event call returns or you use the begin/invoke and invoke pattern. There you also use this push model because you want to decouple your progress from the progress of this other operation. So what is the difference in that versus maybe a poor man's implementation in the sense of a lot of people are used to spinning off another thread in order to go and pull data and they may feel that they solve the problem by simply letting another thread worry about it. That's fine because when you let another thread worry about that that's kind of an implementation detail but now you still have to create a mechanism how that other thread signals to you when it's done. And again, the.net Begin Invoke and the Invoke Pattern is a good example because it gives you two ways to deal with that. One way is you can give a call back to the Begin that will be called when it's done, or you can block on the async results. So it allows you to both kind of block or gets called back. And so what I'm trying to do with Reactive Framework is to kind of separate and formalize both these models. So the pull model has already formalized with the enumerable so if you have a source that you pull values from, that source implements IEnumerable but we don't have anything that formalizes the push model. So if I have a source that pushes the stuff at me, what is the interface for that so that I can have multiple types that implement that source such that just like with Enumerable I can write libraries that only depend on the interface but not on the actual type. I've read up on this little bit. This is then the mathematical dual to LINQ to Objects. So the mechanism at which we design the interface, we're using this trick of mathematical duality but that sounds really scary. It sounds like I need a PhD to understand what it means. Exactly and that's not thread also. Let's go back to this simple example of a button. Excellent. Now look at a button. What is a button? In my opinion, a button is really a collection. It's a collection of clicks. That's potential clicks. Well, no, but it's really a click... Oh, I see. That's just true. Because you get to click events, right. Oh, I see what you're saying. Page 3 of 10

4 So in some sense it is a collection but it's not a collection that you pull from, but it's a collection that pushes the values at you. It doesn't really matter that I don't know how many there are or that it never ends. use coins. Not if it's just a collection. It is typically a collection. Yes and so in my talks I often And so I'm really begging Scott to give me the next round. That's not a nice feeling. No, it's not. What I rather have is I want to have the push model where I tell Scott, you know, whenever you have a penny just throw it at me, so push it at me. Oh, okay. And now look at this, now I'm getting rich, it's like a jackpot in the casino where it's just the money comes in. school radio here. here, all right. And here let's do some old We have a bag of pennies The old school on radio where money is flying at you at this point. So that's kind of the difference between the pull model and the push model. Yup and now you can visualize, and my math teacher always says if you want to explain something, explain it with money. All right, let's see how we're going to use the money in that. model. So let's start with the pull So a pull model is a -- so Scott is going to hold the money. So I'm the button, I'm going to hold the money here. So he's the collection and now I have to ask Scott "Move Next." And now Scott of course is kind of teasing me and he's not giving me the money. He's letting me wait. So now he gave me one. And you may well be doing other things but you're not as much worried about waiting around for me to give you that money. Exactly because I can just have like a cup and I can tell you put the money in the cup and then I can go on and do other things. So that is kind of the basic idea here between the push model and the pull model. Then what Rx is is basically two interfaces that represent push-based collections, and the push-based collections, let's go back to IEnumerable to explain how the pull collections work. So in IEnumerable you first say Get Enumerator, and then when you get the enumerator you can call Move Next and then you get Current and then you call Move Next and then you call Current and then Move Next until it falls and then you're done. again. get the next penny. sense. And now I say move next I'm thinking about it. He's thinking about it and now I Okay, yeah. All right. It makes Now let's look at how you would do push collection. So with the push collection, instead of saying Get Enumerator, you give the push collection a call back to say whenever something happens notify me on that thing. Now, how do you get notified? Well, with the Enumerable you can be notified for three things. You can be notified with the value, that's run move next reader is through, and you say Get Current. You can be notified of the end of the Page 4 of 10

5 collection, that's when move next return is false, or it can throw an exception. Many people don't realize that. But if I call Move Next, that might throw an exception. So there are three possibilities. There are three possible values, a normal value, termination or an exception. Now the same thing. In the push-based collection, when I hand you this interface you can tell me three things. You can give me a normal value like a coin. You can tell me I run out of money, don't expect anything more, or you can send me an exception and say something went wrong. no money. I've had a heart attack, there's Exactly. I'm not available. And so that's what we call the observer interface which is something that has three functions: on next which gets a regular value, on complete it that indicates termination, and on error where you send me an exception. Now, for the listeners who have been thinking about this and they're listening along with us, they maybe saying "Well, I've never personally called Get Enumerator. I've never really thought about IEnumerable." They've been viewing that through the lens of foreach. They've been reading that through the lens of Select and LINQ. Exactly. The DSL that is LINQ has been hiding the fact that this is really happening. Exactly and so we do exactly the same with Rx just like you hide the whole mechanism of Get Enumerator, Move Next, and foreach or in particular now it Link in Where, Select many group by, and all the sequence operating you can write LINQ Query over those. We have this implemented exactly the same operators on this observable collections. Observable collections maybe confusing because there's also the observe collections in WPF as well on this IObservable collections or these push collections. So it will be clear, what we know of as observable collections in WPF are not IObservable collections as it relates to... No, although they could implement IObservable. Oh, well, they do. They signal an event whenever something changes which is like every event you can view as an Observable. And so we've implemented all the LINQ operators over this IObservable-based collections and that's why sometimes people call this LINQ to Events because an Events' dream like a button, button clicks is an example of something that is in push-based collection. Now the nice thing is that you can write very compositional things now using LINQ Query that you could do before. Imagine that you want to write. Everybody is familiar with this, in Visual Studio when you have IntelliSense, whenever you type something IntelliSense doesn't show up immediately. Only when you pause for a little while, then IntelliSense shows up, otherwise, it will drive you crazy. You dive and then IntelliSense would go up and down so it kind of pauses. So when you pause for a little bit, IntelliSense shows up. That's now an operation that I can define on any event stream. So imagine that I have a button in my UI and if you click on it really fast I don't want to call an action whenever you click on the button. Only when you click on the button and then there is no click within a shortened time period. Hey everybody, this is Scott coming at you from another place and time. No doubt you probably bump into testing tasks now and then in your work and you know writing functional test is probably not your favorite thing. It's kind of difficult. It takes time and the results can be dubious. Well, get ready to start liking tests, thanks to Telerik. With the new WebAii testing framework, building web automation tests is a breeze. You've got code automation with advance ASP.NET AJAX and Silverlight applications. You can write a single test, have it execute against multiple browsers at once. You benefit from rich API, there's LINQ support, integration with Visual Studio unit testing, also NUnit, xunit, and MbUnit, not to mention the free wrappers for a Telerik RadControl for ASP.NET AJAX and Silverlight all shipping with Telerik's new testing tool. One of its best features, the WebAii testing framework which is developed by ArtOfTest, is absolutely free. If you already got hooked on WebAii testing framework, start using it right away. Go to for more info. Thanks a lot. Page 5 of 10

6 Right, that's the kind of thing where that will be kind of difficult. I think I'd make a timer and I'd keep track on how long it's been. Exactly. And I think it would probably take a little thought, eight or nine lines a yak and might have some raised conditions and some weird behavior. Exactly. Plus if you now want to do that for a KIOP event you would have to write everything again. paste that... Oh, yeah. You will have to copy and The whole state machine. Exactly and so what we now can do, if we expose your events using an IObservable then you can reuse that same library that we wrote to do that and apply that to any event source. Another interesting... Before you move on, can you say a little something about what that syntax might look like because I'm familiar with from P and people, that kind of -- what does this look like? Exactly the same thing. So let me try a little bit of experiment. This is hard to explain in words but my old professor told me if you cannot explain it in white ink, you cannot explain it at all and so I'm explaining it in white ink which is words. Thank you for that. So let's look at a simple example of an AJAX application. In an AJAX application usually it's just the following. There are some UIs and based on a UI event, like a key brush or a button click, you're making a service call to some web service which might take time and imagine you're using a service reference that's a resurgent event. The results come back and then you want to update the UI. So here's how you would try this using LINQ. You say From value in UI event, From result in surface call based on the result of the UI event, select the result of the service call. So you have a little Query that joins the stream of UI events with the stream of service reference results. I see your head here exploding. Yeah, I know. Yeah, my head has exploded and it's leaking unto your floor. So you've just taken what would have been the hooking up of an event handler which would be one line of code up off somewhere, and the top of my file, the event handler itself, the method call, the stuff that I would have to react to I'd have to dig it out of the property, the parameters and distill it down into one terse but readable single line of code which is essentially what LINQ does. Yes, exactly and the nice thing, and this is really the power of LINQ. I think we're still underestimating the power of LINQ because a lot of people when they hear LINQ they think maybe LINQ to Objects and maybe LINQ to SQL or LINQ to Entity. Uh-hmm. But LINQ can work on anything that implements the sequence operators and in this case this push collection also implements the sequence operators so you can write LINQ Query over them. So all the pushing, all the announcing, all the threads, all the synchronization, all the event throwing is hidden entirely. Inside the sequence operators. Inside the sequence operators. Yes and so you can do that once and for all and so we're spending a lot of time and when you came in you saw that I was kind of talking with my team. We're spending a lot of time making these things correct and especially the edge cases and raised conditions and so on and search that you can then freely compose these kinds of simple building blocks in bigger ranks. What about where or is that when will I use a where or filters those kinds of things? Here's an example. Suppose you have your mouse and you want to restrict your mouse to stay within a certain window in your screen, in certain blocks. I was doing this. Just last week I was doing this. Well, so what you do is you take your mouse moves and you just say where expositions is less than, you know, within the boundaries and the why position is where the boundaries and now you only get events from the mouse within the... So you're actually filtering the creation of events. You're saying I didn't want to know about the events... Exactly. Page 6 of 10

7 If it doesn't meet this. Because this is such a classic problem and I always get nailed with the I'm trying to drag something and I didn't think about the mouse move, with the mouse button down it's different and when it's up, dadadada. And you know, the best way to crash a new program that does a lot of drag and drop is to grab something and just start shaking the mouse around and see whether or not they're off. They've been off by one pixel or negatives, move it on to another monitor... Yeah. Change different coordinates and system, that's a lot of code. Yes and funny that you've mentioned it. Drag and drop is one of our famous examples and it's like also an extra size and it's incredible in how many ways you can actually write drag and drop using Rx and if you go to our forum or I think there's also an example in the 101 Rx Samples to do that. Talking about writing UI programs, a lot of people think that when you're writing UI programs they are hard to test because for example I have to test your program that does drag and drop because how do you test it because you have to maybe have a real mouse to move because, you know, how do I simulate my mind, so how do I write a mock mouse stream. If you use Rx, it becomes trivial because what you can do is you can replace the implementation, the source of the mouse move events by something else say an array... collection events. There's the collection, it's the Exactly. So by making events first class and allow to kind of blog in a different implementation, that's kind of one of the big sources of power of the Reactive Extensions. Events in.net are beautiful things but they're not first class. What I mean by first class is that you cannot take an event and put it in an array, or you cannot take an event and pass it as a parameter or return it from a method. An event is kind of tied to the class in which it's declared. What we do with Rx is we free events from the kind of prison of the class and now events become first class things that you can put in an array, pass around, and now it becomes really easy to create a mock source of events because it's just like any other type. And by including them into the LINQ ecosystem just as, you know, that they are as first class to system.object right there. Whether I'm looking at events or XML or SQL or file systems. It's all what I'm comfortable with already. Yeah. How do we get into this now? Help me understand the state of the project. Where is it, what's the ship vehicle, how do I get it. The listeners will be interested in this. Where can they use it and where do you think it's going? Okay, so that's a good question. So the interface, there are two interfaces, IObserver and IObservable, shipping in.net 4.0 so there you can get them... They're inside of System.Core? They are in System.Reactive. A collection. Systerm.Reactive, okay. Yeah. Or System.Observable. And then you say to enumerable on that array, so that's your input and then you can look at that, the output stream, turn that into another array back and then you can just compare that to the expected output. That's right. So I don't need a mock mouse because all I was reacting to before were events that were in a collection. I just simply make that a collection and pass it in and the data is the data. But that's the namespace, but they're probably in the System.Core physical DLL. Yes, I'm sorry. Yes, I'm here confused because we have like many, many versions that I will explain now. Okay, good. The interfaces are in.net 4.0. Page 7 of 10

8 The reason I sound a little bit confused here is because in.net 4.0 we introduced something really beautiful which is co and contravariants, and since these are interfaces they are co and contravariants. The Observable is covariant and the Observer is contravariant. You see, you might want to take a moment because a lot of our listeners don't necessarily speak English as their native language and they're going to be off looking this up and they may or may not be familiar with the terms of covariant and contravariant so let's take a brief moment. So what covariant means, and many people that have used collections in.net will have discovered that, let's go back to arrays. If I have an array of bananas, I can post that where you need an array of fruit because banana is a sub-type of fruit so if I have an array of bananas and you need an array of fruit I can pass you that array. Now, if you expect an enumerable of fruit, I cannot pass you an enumerable of bananas because enumerable until.net 4.0 was not covariant. So the fact that even though banana is a special kind of fruit, an enumerable of banana was not an enumerable of fruit. So this was basically another way to phrase it as that array, as simple as it is, was a first class citizen and IEnumerable was not a first class citizen. In some sense it's more that it's not a first class but it's defected, it's a generic type that has a type parameter but the sub-typing, the inheritance relation is not carried across the generics. So then now the beautiful thing that you've had in.net 4.0 because of that is the ability to do this with events. So that's why we have that in.net 4.0 but now when we back port it, Reactive Framework, to 3.5 there is no covariant there or there is covariant but C# 3.0 doesn't expose that so we have this separate implementation for that. Then we have a separate implementation for Silverlight and a separate implementation for the Compact Framework. So if you go to DevLabs to ask about shipping vehicle, so on Devlabs we have installers available with the full framework for each of these platforms, each of these versions of.net and so they're all kind of slightly different. Another interesting aspect here is that in Rx you mentioned a while back that if you want to do something asynchronously you spin off a separate thread. TPL. In.NET 4.0, we introduce the Task Parallel Library. Task Parallel Library and so we said, well, in case you need to introduce concurrency why aren't we leveraging the TPL? So Rx is built on top of the TPL but in 3.5 there is no TPL so we work together with the PFX team and back port it... Extensions. PFS is the Parallel Framework And we back ported that to 3.5. So if you download Rx from DevLabs you get an implementation of the parallel framework for.net 3.5. All right. Let's see if I understand this because if I understand it I'll be able to say it back to you. So the Reactive Framework and the interfaces that support it are in.net 4.0. they'll have that. Yup. And when.net 4.0 ships Yeah. They can go up and get implementations for Silverlight, implementations for Compact Framework. Those are the two primary things, Silverlight and Compact Framework? No. Silverlight, Compact Framework 3.5, and for 4.0 the implementation of the sequence operation. Because in 4.0 it's only the interfaces that are there. Right and that will be supported because it's in 4.0. The back port to 3.5 is still a LAMP thing or is it fully supported? It's all LAMP but we're kind of, you know, what this fully supported means... Well, I guess what I'm saying is if I'm a big corporate developer and I'm going to tell my boss I should use this, will he be more happy if I use the 4.0 version than if I use the back port, the 3.5? Page 8 of 10

9 To be clear, the 4.0 version, only the interfaces are in the BCL. DevLabs. The sequence operators are on Now I'm talking about can I use this. We have a very liberal license... Oh good. Where you can use this. So it's kind of different than in the BCL but if you read the license the way I think of it is that we're trying to take away all the barriers for people to use Rx. So no one should be afraid of using this. It's not a skunk work thing. It's the real thing with the team behind it. Now interestingly at the beginning here you're in the Cloud Programmability team and we haven't said anything about the Cloud. So how does all this, what we've just talked about, fit into the Cloud. So the Cloud is all about -- let's say the best way to say it is the way I look at the Cloud is that it's mashing up services from different sources into a client. Now, all these services to get to them is an asynchronous call. You have to go across the network and make an asynchronous call. Now, on the client you have to synchronize and orchestrate these different services which is also an aspect that we haven't talked about but which is very important. Imagine that I'm making two service calls or three to three different translation engines. Now I want to wait until two out of three have returned the result. That's classic kind of a problem. That's the kind of thing where the businessman, the suit that signs my checks can say it very easily, "Hey Programmer, call these three. Two out of three within five seconds and then use them. If the third one doesn't come back, don't worry about it. If only one comes back, give up and throw an error." And he'll say that was crystal clear, and you're going to think, "All right. Well, that's about 60 hours of work." Exactly and with Rx that should become easier. That's what I mention at the beginning democratizing the Cloud. Those are the kinds of scenarios that I want to make super, super easy. So one of the things that's also in Rx is something called the joint patterns where you can write rules. Think of like Outlook rules that you have in your inbox. If a message comes in the inbox and it satisfies these things then put it here. You can write the same rules on event streams or on a synchronous computation. So if these two come in, you do this. If these two come in, you do that. So you can write at a very high level. You can write very concise synchronization logic to orchestrate service calls and event streams, etc. You know, I'm having little kind of like firecrackers going off of my head because I'm starting to realize that it makes total sense why you would be working so closely with the PFX team, with the Parallel team because they are democratizing multiprocessor and threading. They're trying to make concurrency accessible as are you. You're going to make this kind of concurrency accessible. Yes and for example, here's a concrete example. If you take a task, you can take a Task and turn that into an Observable. So if you have any API that works with Task, you can expose it as an IObservable and in some sense that's comparable to taking an array and viewing that as an IEnumerable. So a Task has a lot of special properties and a special operation but now I want to glue together a task with button clicks and that's what XLR allows to do because you can express both in terms of this higher level interface. This is really interesting. I'm trying to realize that looking at the way that you've integrated with LINQ, the way that Parallel extensions seem to integrate with LINQ, that you're going to be able to write very, very clear and crisp statements that will say things like fire off these services when this comes back, go off in these cores and use four out of the eight available cores to process this information and let me know when it's done. The code you write starts to look more like what the businessman in the suit actually said. Yes, exactly and that's kind of the whole point of LINQ where you're raising the level of abstraction where you can write these things in a much higher level way where you abstract again. We've mentioned this notion of abstraction a couple of times. All the complicated locking and so on is now Page 9 of 10

10 hidden in the sequence operators such that you as a programmer only have to -- it's like Lego blocks, you can kind of now connect these together and then inside these blocks there's a lot of complexity but that's all hidden for you. This is one of the things that I've been saying kind of more and more and I feel a little bit like you're validating what I've said which is in.net 4.0, and I'm going to sound like a fan boy here of my own company, the Lego blocks are the right size. Before it was like the tiny little one piece Lego and then the big ones that you give to your 2-year-old child and you try to make them work together and it doesn't. But I feel like more than ever that Lego blocks are the appropriate size for most of the business problems that I'm trying to solve. Yup and I would agree with that and so we're writing another samples. As you say, even though I made this myself it surprises me everyday when I write a sample how beautiful and how elegant you can describe problems. It's like saying, okay, here's a problem and you scratch your head a little bit and then, oh, it's like a little poem, your code is like a poem and it makes programming a lot of fun when your code looks beautiful and kind of ties in and does exactly what it needs to do without any kind of noise. That's what kind of gives me pleasure in life as a developer. Well, that's fantastic. Eric Meijer, thank you so much for sitting down with me today and sharing this framework with me. You're very welcome. We'll put the links up on the show site that you have access to all of this stuff and maybe we'll come and see Erik again sometime. This has been another episode of Hanselminutes and I'll see you again next week. Page 10 of 10