Coffeehouse Thread

15 posts

Rx -> How are you using it? What do you think?

Back to Forum: Coffeehouse
  • User profile image
    Charles

    Niners,

    Who among you are using Rx and how are you using it? Beyond that, what are your impressions of the technology?

    C

     

  • User profile image
    JoshRoss

    I have watched many of the interviews and tried to use it a little. From what I can remember, I had some trouble with it, specifically involving some idiosyncrasies of visual basic. I really like the idea that it fills a placeholder to complete a conceptual symmetry in the core programability scape. However, I struggle to use it to solve, or even simplify, one of my existing problems. Once I do this, perhaps I will work on the iQbservable.

    Bart

    If it's worth anything, I welcome others to go through the soon to be 101 Rx samples. Does anyone talk with Richard Hein? I would like to get him in on this.

    -Josh

  • User profile image
    JoshRoss

    I could probably use the fork-join somewhere, and it could be handy to have a robust, yet simple, scheduler.

  • User profile image
    Charles

    Thank you, Josh. What do think of the mechanics of composition (coding)? The question seeks to answer the arguable notion that Rx is complex, conceptually, which perhaps also surfaces in how you compose algorithms with it. That said, you don't have to use monads explicitly -> Rx does that for you Smiley

    C

     

  • User profile image
    JoshRoss

    Around the time Rx came out, there were a couple of other libraries also being released. The CCR and the PTL, are the top two that stick out in my mind. Both had their own solutions for dealing with asynchronousity, parallelism and failure. If you thought monads were complicated, try wining mindshare.

    And now we have async. In my mind, the best thing about language integration, is that I don't have to worry about taking a dependency on a library, that might not be supported tomorrow.

    -Josh 

  • User profile image
    Charles

    @JoshRoss: Good point. However, libraries are not on similar evolutionary cycles as programming languages. Further, as you learned, Async is only possible due to integration with Tasks, a library construct.

    Each of the technologies you mentioned support specific scenarios or set of scenarios. You compose robotic computation with CCR. Parallel tasks with TPL. Stream-based asynchrony with Rx. Monoasynchrony with Async (so, the awaited result is a Thing of Thing, not sets or streams of Things).

    C

  • User profile image
    exoteric

    So far I've not needed the advanced capabilities of Rx. But I don't find it hard to understand. Some operators are perhaps a little hard to understand but the overall semantics and concepts has been excellently covered on Channel 9 by Meijer, Beckman, Dyer, de Smet, van Gogh & co.

    Interesting term, monoasynchrony. Yes that fits well since async is not about a stream of results whereas IObservable is.

    I need to meditate a little more on concrete use-cases, because clearly the concept is powerful.

  • User profile image
    JoshRoss

    @Charles: I understand where you are going with your point about the rate library innovations vs the rate of language innovations. However, this seems to apply more to officially sanctioned languages, and not so much to experimental languages like Axum or Spec#.

  • User profile image
    Charles

    , exoteric wrote

    So far I've not needed the advanced capabilities of Rx. But I don't find it hard to understand. Some operators are perhaps a little hard to understand but the overall semantics and concepts has been excellently covered on Channel 9 by Meijer, Beckman, Dyer, de Smet, van Gogh & co.

    Interesting term, monoasynchrony. Yes that fits well since async is not about a stream of results whereas IObservable is.

    I need to meditate a little more on concrete use-cases, because clearly the concept is powerful.

    The concept is also beautiful.

    Thank you Erik. Wes. Jeffery. Bart. Brian. Greg. Ralf. Channel 9 will continue to pump functional information through our media tubes. Certainly, there is much more to do in this regard.

    C

  • User profile image
    JoshRoss

    I would like to see a follow up questionary asking the 19 responders if they watch any of the channel9 videos. There is nothing like on job training.

    It's good to see at least one response from an Excel/SQL user, that knows that they are using every day functional programming.

    Something that came to mind was using functional programming techniques for testing. If there is any place for functional programming, its generating a bunch of data and reducing it to a set of outcomes.

    As a side note, it doesn't seem that head in the box was one of the 100 participants in the experiment.

    -Josh

  • User profile image
    contextfree

    I had my own jury-rigged ghetto version of Rx (made before the official release, based on the initial videos etc. that were the only thing available at the time) that I used at my previous job where we had a distributed document-processing system with streams of document metadata coming in from extractors on multiple machines. The approach worked well but my implementation was pretty hackish, I haven't gotten a chance to use the official .NET version yet because there hasn't been much event-stream-y stuff at my current job. I did use RxJS a bit for some Ajax call chaining, and honestly it was probably a mistake as it was overkill for what I was doing (to be fair my struggles with it were probably mostly due to my inexperience with Javascript in general).

  • User profile image
    Richard.Hein

    @Charles:  I've been using Rx where ever I can, but haven't had as much opportunity as I'd like up to now; however I firmly believe that's changing a lot, both in my life and in the development community in general, as the requirement and desire for asynchronous code becomes more commonplace.  It will be more commonplace in large part because of things like TPL, Rx and the new Asynch CTP, as it's becoming something that you can do in a reasonable amount of time and far less code, once you understand the concepts.  

    It was pretty much something you'd avoid if at all possible before, because of the complexity of the code, especially if you are trying to compose asynch computations ... that was a nightmare.  Rx greatly simplifies the composition of asynchronous computations, so it makes you more willing to try in the first place.  Once you start doing that, your programs become much more responsive, so you start to think about everywhere you may be able to do something asynchronously, or event based.

    I still have a lot to learn about it, and really have to write more code using it.  I've used Rx for plenty of event handling, but that's the easy stuff.  Beyond that, I've used it in "real life" code for asychronously reading in CSV files and processing them.  It worked well, but was difficult to get right.  Jeffrey van Gogh then wrote some blog posts on the problem which I wish existed before, but I learned a lot from that.  I've also used Rx for unit testing by simulating event streams.  I'd like to do that a bit more in the future, with the newer releases of Rx, because they have some features that would be very useful for that.

    I hope I'll soon get to use it much more, and expect I will.  I'm in the middle of transitioning to another dev team, a significant web application, so hopefully I'll find opportunity to exploit Rx in a real, significant product soon.  I imagine RxJs will apply a great deal. 

    When you start using Rx a lot, it changes the way you code quite dramatically.  It's fun to puzzle things out.  It really is mind-bending.  There's the simple stuff, and there's the incredibly complex side where you are thinking about monads all the time, and you have to make marble diagrams to figure out what the heck is happening.  A lot of developers are scared of it.  I love to learn about this stuff, but it's not easy.  A lot of developers I work with don't yet really understand LINQ and lambda expressions, and so forth yet, let alone monads.  It's important to understand LINQ to appreciate Rx, and functional programming concepts definitely helps, as well as trying to understand monads. 

    When I get into deep discussions about WHY Rx and so on, vs. just doing it the old, hard way, ultimately I have to bring up things like side-effects, closures, continuations, CPS and eventually monads, to explain why it provides true compositionality vs., the old way.  In the end I find that is the hardest thing to really get into someone's head, because I end up having to use some mathematics to explain functional composition, and how LINQ and Rx help you achieve it.  Everything else is something you can do the "old" way, but true compositionality is only acheivable via monads (at least AFAIK).

     

  • User profile image
    DouglasH

    I have been looking at the MVVM with rx integrated.  UI in general is Async, in that it is a STM be it GDI or WPF.  It is also highly event based so it makes sense, at least for me) that RX would be a good glue to allow compostion. 

    The one I am looking at is http://blog.paulbetts.org/index.php/2010/06/15/reactivexaml-a-compelling-combination-of-mvvm-and-reactive-extensions-rx/

     

    Although, there have been several discussions on stackoverflow and general musings accross the net. 

    D

  • User profile image
    exoteric

    Well one thing I'd like to do before or during xmas hollidays is converting some LINQ to Objects code to Rx and performance test the hell out of it. I know that's probably not what I'm "supposed to do" but I like to test the scalability limits of technology and since whatever LINQ to Objects can be used for, I can more or less apply Rx to, it's actually not that hard to find use-cases for it, courtesy of duality. (Appropos)

  • User profile image
    JoshRoss

    I'm working on Bart's video and I had to pause to say that I had not seen the .ObserveOn function. Awesome. Now back to the video.

    -Josh

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.