Why cannot IObservable<T> be used without Reactive(Rx) extension for .NET?

Question

Attempting to understand why and when I would need to use Reactive Extension (Rx) for .NET, I came to question "C# 5.0 async/await feature and Rx - Reactive Extensions" the reading of which with its references resulted in more questions than answers.

The referenced in the latter article Task vs IObservable: when to use what? seems to refer to usage of IObservable synonymously (or interchangeably) to usage of Reactive (Rx) extensions for .NET

What does, for example, the phrase from the mentioned article:

Your code will require the reactive extensions if you chose to return IObservable

wanted to say?

Both Task<T> and IObservable<T> are part of .NET which I am using without any reference or setup of Rx.
Why do I require reactive extensions in order to retuen IObservable?

What does RX have to do in discussion of Task<T> vs. IObservable?
And why is their usage being juxtaposed?

Answer 1

It's actually due to ease of implementation. You should never attempt to implement IObservable<T> yourself; Rx has every implementation you could need done correctly and efficiently.

The Rx design guidelines specify the actual semantics of IObservable<T>. Note that the MSDN example implementation is completely and utterly wrong.

Update:

The MSDN example code fails in the following semantics (the reference numbers are the design guidelines from the document referenced above):

• Does not enforce the Rx grammar (4.1).
• Does not unsubscribe automatically after OnError (4.3).
• May not properly handle corner cases (6.1, 6.2).
• OnError does not have abort semantics (6.6).
• If a subscription is disposed and the same observer is re-subscribed, then the original subscription is no longer idempotent (6.17).

And that's only if the custom implementation assumes that all calls to TrackLocation are serialized. In the Rx world, this is hardly ever the case.

Note that it is possible to fix all of these problems with the Rx Synchronize operator, though you still have to make the assumption about serialized calls to TrackLocation.