Share via

Reactive Extensions 2013 Year in Review

  • Article

This past year saw a number of changes with the Reactive Extensions (Rx).  The team, with the help of the community, MS Open Tech and others, we have been super busy.  We thought we’d take a little bit of time to recap the year, what we did and what we plan to do. 

Of course, it cannot be said that there wasn’t change with the Reactive Extensions Team, as Erik Meijer, the founder of the Reactive Extensions, LINQ and many other contributions, left Microsoft so that he could work on Rx on the outside, helping with adoption.  We continue as a team to work closely with him and the community on the future direction of Rx.

Going Open Source

As we announced back in November 2012, in conjunction with MS Open Tech, the Reactive Extensions for .NET, C++ and JavaScript were released as open source under the Apache 2 license on both CodePlex and GitHub.  Since that time, we’ve released a number of other languages which now include:

Some are more complete than others, but we’d love the community’s support with making these libraries better.  Contributing has never been easier to the Rx projects has never been easier.  You can contribute to Rx with examples, documentation, code, tests.  Simply sign the CLA and be a part of Rx!

RxJava

Another great result of our open source work has been the collaboration with such companies as Netflix.  The Netflix engineering team are big fans of the Reactive Extensions, and decided to port the Rx to the JVM in a project called RxJava so that their engineering teams can use Rx on both the client and the server.  It currently supports Java 5+, Clojure, Scala and Groovy.  The Netflix API takes advantage of RxJava, exposing all service methods to return Observable<T>, which allows for flexible composition, and concurrency safety. 

The RxJava project has enabled Netflix developers to leverage server-side concurrency without the typical thread-safety and synchronization concerns. The API service layer implementation has control over concurrency primitives, which enables us to pursue system performance improvements without fear of breaking client code.

Conferences

Late 2012 and through 2013 was a busy year for the Reactive Extensions team for presentations.  In addition, we’ll also be making an appearance at CodeMash in Sandusky, OH.

The Netflix team has also been quite busy giving presentations not only on RxJava, but also RxJS, which they frequently use as well. These are great presentations that show how a company with scaling needs such as Netflix uses Rx across all platforms and both on the client and server.

Release of Rx v2.2

This year also saw the release of Rx v2.2 for .NET, C++ and JavaScript, which was announced on this blog here and here.  What was great about these releases is that a lot of the material for this release was specifically driven by the community.  So, a big thank you to the community for participating and moving Rx forward! 

Promises for the New Year

This year, 2014, promises to be another great year for the Reactive Extensions team with a focus on many things such as:

  • Version 2.3 with ideas around backpressure and other concerns
  • Language parity with Python, Ruby and C++ versions
  • New languages supported
  • And yes, more blogging

Although we don’t blog as much, you can always catch us on Twitter at @ReactiveX!  We publish lots of information about Rx and what we’re up to, so follow us!

Comments

  • Anonymous
    January 01, 2014
    Hi Rx Team, I and my team are really troubled by MS's apparent policy of Open-sourcing code from under our feet. We are in an industry with rather paranoid clients that contractually bar us from using Open Source software. We have immensely enjoyed using Rx but its open-sourcing threw us into turmoil. I feel like we have been betrayed, and will think twice before adopting some new Microsoft framework again, wary of it being Open Sourced later on without prior warning.

  • Anonymous
    January 01, 2014
    Name a single software product open or closed source which doesn't have vulnerabilities? The world's best software engineeres get things wrong sometimes. Don't think for a second that using strictly closed source is going to put you in a better position. I suggest you start educating your clients on the benefits of open source. If you don't your going to find it increasingly difficult to use any library from Microsoft, or any other software house, in the future.

  • Anonymous
    January 01, 2014
    @Vince: I completely agree with your first two paragraphs, but think your third is ridiculous. We serve our clients, not the other way around. If reality were different and we were in a position to educate our clients and change their behaviour, then we'd start by telling them that using Windows XP SP3 right up till support ends is a stupid thing to do. Surely you've heard the phrase "the customer is always right"? Anyway, I'm not getting upset about Open Source per se, but about the Open Source-ing of established products that we may then have to rip out of our codebase at great expense rather than lose more revenue by losing a big (if stupid) client.

  • Anonymous
    January 01, 2014
    @JDT - I appreciate the unfortunate position you're in but I think your clients are the one you should be complaining to...they're the ones on the wrong side of history.

  • Anonymous
    January 02, 2014
    I just wanted to drop by to say thanks so much for open sourcing Rx! Many of our client projects are using them, and our clients don't let us use things without a permissive open-source license. Apache is perfect in that regard. It's been great being able to use Rx this year, whereas previously we were unable to because of its closed-source nature.

  • Anonymous
    January 02, 2014
    The comment has been removed

  • Anonymous
    January 02, 2014
    The comment has been removed

  • Anonymous
    January 02, 2014
    The customer is not always right. The customer is paying you to do it because you know more than they do, and you do them a disservice when you don't give them your expertise. Open sourcing Rx had no negative impact on your project whatsoever, and removing it just because of an ignorant customer instead of educating that customer is foolish. If they REALLY want to pay extra to remove it, well, that's business for you. Microsoft is not going to stop open sourcing stuff because of a couple of oddballs like that customer.

  • Anonymous
    January 02, 2014
    Clients don't need "yes men/women". They need educated, intelligent, trusted people that can help advise them and guide them toward success.  If you aren't doing that you should be fired. The idea that you would have to pull code out of your system because it was open-sourced is hilarious.

  • Anonymous
    January 02, 2014
    Microsoft has used BSD licensed code in Windows since NT 3.5: www.kuro5hin.org/.../7357 You're better off just writing your own OS to protect against this sort of transgression.

  • Anonymous
    January 02, 2014
    @JDT A good consultant should always be educating their clients. I wrote up a blog post which you may find helpful. http://sstools.co/1ddWlCj I strongly suggest reading Mike Monteiro's book, Design is a Job. It applies well to anyone working for clients. I think your company should define their standards and clients have to accept those standards or go elsewhere. This is how Monteiro has grown his reputation and successful business. www.abookapart.com/.../design-is-a-job

  • Anonymous
    January 02, 2014
    @JDT which version of RX are your clients using?

  • Anonymous
    January 02, 2014
    "the customer is always right", even though clearly they are wrong. Wow, I didn't think this attitude towards open source existed anymore...

  • Anonymous
    January 02, 2014
    Hi JTD, Nothing really changed from a deployment point of view, Microsoft still provides signed binaries that you can deploy via nuGet via www.nuget.org/.../Rx-Main, so the fact that the source code is open source should not be a problem per se. On the other hand having the code open source is helping us to improve the libraries with the help of all the great developers that are using Rx today. I hope this can address the concerns you have about Rx being open source. Happy to continue the discussion.

  • Anonymous
    January 02, 2014
    It's time that we developers stand up for what we believe is right and educate our employers / clients / whatever regarding getting the best tool to do the job. It annoys me when tech is made political, especially by those who do not understand technology at all. I had the same issues with my former employer (in the financial industry), with such a backward view of open source. Opening some framework or library's source does not make it any riskier than any other closed-source library, nor does it mean that a home-grown framework or library is more secure and bug-free than open source software. I'd rather use something that's proven and tested by many, than one that's NIH just because people wish to avoid open source. I would understand issues with GPL and commercial software, but there's nothing wrong with what Microsoft did here and in fact their license terms are one of the most open in the industry.

  • Anonymous
    January 02, 2014
    If it's a contractual thing, why not just amend the contract. Include at least Microsoft "approved" or "led" open source projects in the contract. Contracts are there to protect both parties, and can be changed depending on communication. I suppose it's just up to you guys to "sell" the idea to conservative customers.

  • Anonymous
    January 02, 2014
    It's simple, if you don't like, do not use it. If you want really open source, please look for Apache software or other. Microsoft is a private company and with a BIG EFFORT has created a lot of product that at my ends, pays the bills for me and my family. If I do not like any product of Microsoft, I recommend to use another or even I combine different technologies to get what my clients are looking for. Asking a third person or company to give to the humanity what he/she has made with a lot of investment (money and/or time) is out of your mind. I'm sorry if I'm not agree, but is not very fair to ask this kind of things. We all pays our bills, there are a very few people who works on this as a hobby (we follow schedules releases, a lot of stress to be on track and coordinate our teams,...etc). PLEASE, if you don't like this, use another!!! YOU ARE FREE TO DO IT!, then DO IT!

  • Anonymous
    January 03, 2014
    The comment has been removed

  • Anonymous
    January 03, 2014
    JDT, note that Rx versions 2.0.* and prior were closed source, so if that is the version of Rx that you are using, there is no need to remove it from your client's code. Changes to Rx since 2.0 were mainly new features rather than bug fixes (though you should check every bug fix and make sure you aren't affected), so you might be able to stay with Rx 2.0. As others have noted, many Microsoft libraries are being open-sourced these days (e.g., ASP.NET, Azure SDK), so your client may already be using Microsoft OSS, or have had other consultants use it.

  • Anonymous
    January 03, 2014
    Kudos to the RX team for open sourcing all of the RX libs and for supporting multiple stacks!!! As to the question there's just a ton of FUD still out there about open source libraries that Microsoft is publishing. Saying companies should just get with the program doesn't make that go away. From what I have seen a lot of the fear is based on lack of education. Companies are afraid of liability and lack of support. The liability fears come from using code that has been contributed. Support because they want to know if they find issues that Microsoft won't leave them out in the cold. Reality is if you are using OSS libraries that Microsoft it shipping, these are both addressed. For the IP concern, Microsoft does a full legal scrub on any IP that is contributed. Any libraries that it uses it also does an evaluation on to see if there is any substantial risk. As to support, one any 3rd party code is accepted,  Microsoft agrees to support it just as if Microsoft engineers wrote it. The same even for 3rd party libraries, if Microsoft takes a dependency on a 3rd party library (ie jQuery, JSON.NET,  etc) and you use the version of the library that Microsoft ships in the official release (nuget, etc), then it is supported. The caveat to this is if you upgrade. For example if you use the JSON.NET version that ships with Web API you are covered, if you go then an update to a newer version of JSON.NET which did not ship with Web API and you find bugs, etc then unless those can be reproduced in the shipped version, they will not get supported. I recorded a podcast a while ago on this specific topic: www.buzzfrog.se/.../dev-cast-30-microsoft-and-open-source

  • Anonymous
    January 04, 2014
    @JDT This would never happen on Linux!

  • Anonymous
    February 08, 2014
    Hi Rx team, Great work on Rx.  I use it a good bit, but could use even more if it was improved as a Portable Class Library with iOS and Android.  Are there plans to make this possible? Thanks again

  • Anonymous
    October 12, 2014
    The comment has been removed

  • Anonymous
    March 02, 2015
    You're best off just writing your own OS to protect against this sort of transgression. www.nextgenappstore.us