Discussion: UniRx vs .NET Rx(with Unity integrate port from UniRx)

[neuecc]

.NET Rx is very active from v.4.x from in this year.
https://github.com/dotnet/reactive
It has many improvement and has many operators that not implemented in UniRx.

UniRx has many Unity specified utilities and modified to perf for Unity.

[NoxMortem]

This one is both interesting and intriguing. One the one hand I prefer to have common tools, shared among a broad base of developers and contributed by many. This allows usually for high quality libraries and a wide range of functionality - as can be seen with the .NET Rx advantages you list: many improvments and operators.

On the other hand, I really love UniRx exactly for its specialized utilities. I'd say in the end it comes down to if you have the time to support UniRx in the long run as you did in the past. Unity is changing a lot as we can see with #326 and even if you personally do not plan to support it yourself but open it to the community as in #325 I guess the problem remains to see if we really require a split community between .NET Rx and UniRx.

[grofit]

Ideal world

In an ideal world I would LOVE to be able to just use the dotnet-reactive lib (rx.net) and then just bolt on unirx as extensions, but as mentioned in other threads (#300) there are still some problems with AoT platforms and rx.net as well as potentially still having it not entirely being focused on game dev scenarios with ideally low GC and high throughput.

There is also the problem of how Observable is a public static partial in rx.net so its not like you can really extend that class in any meaningful way (i.e how we can do Observable.EveryUpdate), and it becomes tricky if you end up maintaining a UnityObservable.EveryUpdate as either you make it a partial facade for the underlying Observable operations or you make the user require 2 different observable classes for creation of chains. In a prototype branch I made a while back I sidestepped this problem by making the underlying class public and then making all members on it static, so then you could append to it making it easier for others to potentially add helpful conventions to Observable.

Examples of what I mean:

• Example base class
• Example adding via partial
• Example extending in Unity layer

So given that I don't think you could just use rx.net on all unity platforms out of the box it seems like it would potentially be problematic to achieve this ideal world scenario. but if there is any way to achieve this goal I would push for this.

More realistic

The more realistic option for me here would be to extend the use case for unirx so it potentially can be used by any .net framework, so your rx polyfill and helper classes, i.e MessageBroker, ReactiveProperty etc are just all made as generic .net standard projects so they can be a more game dev focused rx implementation, which would be beneficial for users of MonoGame, Godot, Unity and potentially others (as more and more C# engines keep popping up).

I had a quick stab at trying to do this myself and most of the library was easy enough to split up so we have 2 repos the .net layer which has no dependency on unity etc and contains all the basic functionality. The hard bit was trying to add the Unity layer on top as the way the scheduler and other bits are done its a bit too intertwined at the moment, but give you wrote the lib (@neuecc) chances are you would find it far easier to decouple these 2 parts and then have 2 separate repos.

I would push for this as a more realistic scenario which would benefit all .net game devs, and make the library have a much larger audience, as rx.net will have problems on AoT devices regardless of engine, and you have already solved those problems for the most part and added more game dev helpers in which others could benefit from.

There is also the subject of "should namespaces attempt to be the same wherever possible", which I will side step for now, but its worth keeping in mind.

I would potentially see there being 2-3 repos if we went down this route:

System.Reactive (or whatever you want to call the generic .net layer)

Contains core functionality and mimics most of the rx.net functionality with the improved performance and AoT stuff.

System.Reactive.Data (again call it what you want)

Still contains .net standard compliant code with no dependency on unity etc but contains the additional helper functionality which is often VERY useful to devs, like ReactiveProperty, ReactiveCollection, ReactiveDictionary, MessageBroker etc.

System.Reactive.Unity

This would be the only part which depends upon unity and would build off the other layers and add the unity specific stuff like Observable.EveryUpdate and the unity specific async handlers etc.

---

There is also the other option of leaving this as a primarily unity lib and exposing a cut down version for other devs, but realistically adoption wont be that high for devs in other frameworks if its not marketed as a generic .net game dev lib (i.e if you were developing a monogame lib would you relish pulling in a library which was designed for unity and named after unity?).

---

I am in a bit of a unique scenario here where I have an ECS based framework which relies heavily upon rx and it has been a nightmare to make it into a generic .net lib (for users of MG/Godot/Unity etc) as I need to depend on an rx implementation, and rx.net doesnt work in all unity platforms so couldnt use that, and unirx didnt really support the more generic .net ecosystem as well (and was years out of date) so in the end I had to basically rip out a TINY part of unirx and embed my own barebones rx implementation for the innards of my lib then just let the consumer pick rx.net or unirx on the consuming side, but I would have much rathered just picking one library and using that and UniRx would have been perfect if it had more of a focus on the wider .net eco system.

[grofit]

@neuecc Any comments on this as I would really like to see your .net nuget library updated and ideally maintained, so whichever direction you go some feedback would be good.

[RDeluxe]

I'm in the same boat, because I would love to share my logic between a client (Unity) and a server (.Net core).

[grofit]

@neuecc Any thoughts on this, most of the main roadblocks we discussed a couple of months ago are still just sitting there stagnating.

[xahon]

I want System.Reactive operators too :(

[Noemata]

Has anyone else played around with the alternate strategies available for using the .Net Standard 2.0 version of System.Reactive with IL2CPP? If you don't know what this means, you can ignore this message.

[grofit]

I never tried in IL2CPP scenarios but I believe someone else did, the key problem from the discussions we had is the AOT aspect of things which is not easily mitigated in rx.net, I dont know if they have made updates in that area but that was seemingly the last problem we had.

[Noemata]

IL2CPP and UniRx seem to work together without issue. We're just finding UniRx extremely limiting because of the extent to which it veers away from the System.Reactive namespace. @grofit, I much prefer your approach. At least you can then iterate on work outside of Unity. All Unity libs should strive to be .Net Standard compliant first if there's no need for specific Unity tie ins.

[grofit]

Oh yeah UniRx should work fine in all scenarios, I meant System.Reactive didnt (not tested recently) work in IL2CPP due to AOT constraints from internal logic/dependencies in rx.net.

I completely agree with the separation and I did try to take a stab at it, but the way a lot of unirx is coded its very closed off i.e lots of internals and even if you solve all of that with an abstract scheduler notion, you still have the problem of the System.Reactive.Observable object not being extensible so that means the other option is to either create a facade/proxy object to wrap it and add the unity bits or just make the unity bits in another class like UnityObservable but then it makes devving a bit more cumbersome switching between the original or the unity specific Observable functionality :(

Anyway would love someone to do it :D

[Noemata]

I have a feeling System.Reactive will eventually become the measure of how compatible Unity is with .Net. It's also a gotta have.

[shanecelis]

It seems like AOT compilation is the big stumbling block in using System.Reactive with Unity. I made some headway in getting an unmodified System.Reactive.dll to work in Unity even on AOT platforms. I have a prototype that you can examine and try out. You can see the iOS app in action here. It is ugly as sin but demonstrates that System.Reactive + UniRx might be a worthwhile approach to acquiring all the operators while also retaining all the wonderful Unity-specific utilities that @neuecc has put together.

[Fijo]

I started a project attempting to consolidate all the attempts that have been made already and using them to build the most basic features of UniRx that I'm using in one of my personal projects on top of System.Reactive 5.0.0, partially building on @grofit concept.

There's still more work to do but it's a start and I'll try to get a proper clean version out soon.
https://github.com/Cosmic-Shores/System.Reactive.Unity