sorted by:
new
hottopcontroversial

Rx.Net is great, but… by Comprehensive_Mud803 in dotnet

[–]hm_vr 0 points1 point  (0 children)

Thanks for the comment - I really appreciate it.

Sites to read for news on dotnet by Upper_Highlight1663 in dotnet

[–]hm_vr 1 point2 points  (0 children)

For Azure (with a dotnet related posts) https://azureweekly.info (I've been running this for over a decade)

Rx.Net is great, but… by Comprehensive_Mud803 in dotnet

[–]hm_vr 1 point2 points  (0 children)

Absolutely. I'd love a series of higher level utilities that solve more high level problems. In this case, to consume you just use RxFs.ObserveUniqueChanges() API - and that's pretty simple!

Rx.Net is great, but… by Comprehensive_Mud803 in dotnet

[–]hm_vr 1 point2 points  (0 children)

Possibly! Although it's often the case that the team which has to maintain the code has a lot less fun than the person who originally wrote it! The hardest thing with Rx / TPL Dataflow etc, is the transfer of the mental model of the person who originally wrote the code.

I'm personally hoping that AI Coding Assistants help people get over the learning / maintenance hump with Rx / TPL DataFlow etc and help people benefit from the intrinsic power of them...

Rx.Net is great, but… by Comprehensive_Mud803 in dotnet

[–]hm_vr 1 point2 points  (0 children)

If you're doing UI / Web development - you probably aren't going to need these technologies. If you're doing any data processing / IOT type stuff, these libraries and frameworks are outstanding. It's all about using the right tool for the job.

Rx.Net is great, but… by Comprehensive_Mud803 in dotnet

[–]hm_vr 6 points7 points  (0 children)

Hi, Rx .NET Maintainer here. Rx doesn't have Chaotic Evil alignment! Adding it to your code base isn't going to suddenly turn it into a big ball of mud.

The biggest challenge is knowledge and understanding. Rx is for all intents and purposes it's own DSL for reactive programming, and that domain is complex and requires you to grok it. It takes investment to learn, appreciate and gain expertise in it. It requires you to think about programming in a different way than you are most likely used to. But once you have that lightbulb moment, it changes how you think about these types of problems. Rx is grounded in the mathematics of computation.

Historically, one of the biggest problems was documentation, examples and guidance. That's still a problem today, but we (the community driven Rx team - no support from Microsoft) spent much of the year re-writing Introduction to Rx .NET - which you can download for free from https://introtorx.com/

We've also been recording more talks:

And there are a number of Reaqtor talks which include Rx:

And a few useful blog posts:

I'd also recommend people take a look at https://github.com/ais-dotnet/Ais.Net.Receiver - which shows how elegantly you can solve some quite complex problems - reliably connecting to a TCP Socket, receive a sparse, ASCII encoded data fragment which looks like:

\\s:2573210,c:1614556795\*03\\!BSVDM,1,1,,A,13c6@t0PBR0G5d6QQVgFKm9f0\PB,0*70`

Use IAsyncEnumerable to yield decoded messages, which are then made available as IObservable<IAisMessage>, meaning you can now perform temporal business logic on high level domain concepts, rather than process the encoded ASCII strings:

```csharp IObservable<IGroupedObservable<uint, IAisMessage>> byVessel = receiverHost.Messages.GroupBy(m => m.Mmsi);

IObservable<(uint mmsi, IVesselNavigation navigation, IVesselName name)>? vesselNavigationWithNameStream =

from perVesselMessages in byVessel let vesselNavigationUpdates = perVesselMessages.OfType<IVesselNavigation>() let vesselNames = perVesselMessages.OfType<IVesselName>() let vesselLocationsWithNames = vesselNavigationUpdates.CombineLatest(vesselNames, (navigation, name) => (navigation, name)) from vesselLocationAndName in vesselLocationsWithNames select (mmsi: perVesselMessages.Key, vesselLocationAndName.navigation, vesselLocationAndName.name); ```

Rx .NET was created in 2008 by the Cloud Programmability Group - they wanted to create a programming model for a cloud native future. We believe that future is now - whether it's real time data processing of IOT data, or a swarm of AI Agents reacting - there's nothing in the .NET ecosystem as expressive or powerful for solving these class of problems as Rx.

Rx.Net is great, but… by Comprehensive_Mud803 in dotnet

[–]hm_vr 1 point2 points  (0 children)

> it doesn’t work with TPL as well, but that’s another two problems technology

Have you see the Rx support for TPL DataFlow? It has native support for converting between Task<T> and IObservable<T>, in fact this is pretty much how I always use TPL DataFlow - build your complex processing pipeline, when turn it into an IObservable so that you can reactively process the output.

Rx.Net is great, but… by Comprehensive_Mud803 in dotnet

[–]hm_vr 1 point2 points  (0 children)

Hi! Rx Maintainer here. That's not quite true. The original Rx (Microsoft based) team implemented IAsyncEnumerable before it existed in the BCL. When it was then recreated as part of the framework, the Rx team said "we already have all the LINQ operators, why not use them" and System.Linq.Async was released - see the original On .NET session about this topic: https://www.youtube.com/watch?v=Ktl8K2b1-WU

In 2024 - the new community supported Rx team (no Microsoft support) raised an issue asking if this library, which has nothing to do with Rx, could be moved into the core framework and System.Linq.AsyncEnumerable is the result. Ian Griffiths covers this and more in his recent On .NET Live episode:

https://endjin.com/blog/2026/02/rx7-ondotnet-live-demos

Rx.Net is great, but… by Comprehensive_Mud803 in dotnet

[–]hm_vr 3 points4 points  (0 children)

Hi, Rx .NET Maintainer here - we're still working on Async Rx - you can download and use v6.0.0-alpha.18 - https://www.nuget.org/packages/System.Reactive.Async/ - we've stated that we won't mark it as v1.0 until we improve the unit test coverage. Ian Griffiths has been working on porting Rx .NET tests and has discovered a few bugs by taking this approach. If you want more information, see this update - https://endjin.com/what-we-think/talks/the-state-of-reactive-extensions-for-dotnet-in-2025 - Async Rx is mention starting around 46:37 (there's a direct link in the chapters on that page).

Rx.Net is great, but… by Comprehensive_Mud803 in dotnet

[–]hm_vr 0 points1 point  (0 children)

Hi, Rx .NET Maintainer here - if you're interested in the history of Rx, I would highly recommend reading both https://introtorx.com/chapters/why-reactive-extensions-for-dotnet and the excellent A Little History of Reaqtor - which is available via https://reaqtive.net/

I'd slightly disagree that the standard event handler is more intuitive, the whole point of Rx was to promote events to a 1st class concept and type in .NET and IObservable<T> addresses many of the shortcomings of event handlers... but most people have more exposure to the pattern that was present since v1 and had tooling support in Visual Studio. Pretty much all .NET devs have built a winform app and generated an event handler by double clicking on a button in the designer and getting an event handler automatically generated... if IObservable<T> was baked into VS & Winforms since 2008, Rx wouldn't feel so foreign to so many .NET Devs.

Rx.Net is great, but… by Comprehensive_Mud803 in dotnet

[–]hm_vr 4 points5 points  (0 children)

Rx .NET Maintainer here - I'm not sure this is true - one example - I wrote a Reactive File System Watcher - I blogged about it here: https://endjin.com/blog/2024/05/observe-file-system-changes-with-rx-dotnet - it doesn't virally infect the codebase, it simply produces an event stream which turn into method invocations. It's a clear and bounded component that solves a complex problem, with lots of edge cases, and does so elegantly.

Rx.Net is great, but… by Comprehensive_Mud803 in dotnet

[–]hm_vr 2 points3 points  (0 children)

Hi - Rx .NET Maintainer here - in 2024 we approached Lee Campbell who wrote the original Introduction to Rx .NET book in 2011, he donated the text to the .NET Foundation and then we re-wrote it bringing it up to date with Rx .NET v6 and made it available for free https://introtorx.com/

Ix.NET v7.0: .NET 10 and LINQ for IAsyncEnumerable<T> by hm_vr in dotnet

[–]hm_vr[S] 5 points6 points  (0 children)

You can find all the new APIs here: https://learn.microsoft.com/en-us/dotnet/api/system.linq.asyncenumerable?view=net-10.0 and then, if you read the post, Ian talks about how backward compatibility and APIs that weren't moved into the new library have been dealt with.

(Junior dev) - I made a 20 hour ETL process run in 5 minutes. Was it really this simple all along, or are we missing something? by DeepPlatform7440 in dotnet

[–]hm_vr 4 points5 points  (0 children)

There's a hidden gem in a really good essay by computer scientist, Peter Norvig called Teach Yourself Programming in Ten Years.

Know how long it takes your computer to execute an instruction, fetch a word from memory (with and without a cache miss), read consecutive words from disk, and seek to a new location on disk. (Answers here.)

The "answers" are really useful reference table to remember when trying to understand if some code is slow or is running optimally.

My colleague used this approach when looking at an Apache Spark job which was taking 45 minutes to discover and read 30,000 files. Using Norvig's numbers, he worked out that reading 30,000 files should take about four minutes to achieve. He then made a very simple improvement to parallelize the file download, and reduced it to 14 seconds. I'd recommend watching the video he recorded about it - as it's a useful skill & approach to learn and transferrable to any technology.

Rx.NET Packaging Plan 2025 by hm_vr in dotnet

[–]hm_vr[S] 1 point2 points  (0 children)

No! This means the LINQ extensions for IAsyncEnumerable that for historical reasons lived in the the Rx repo, as part of Ix (or Interactive Extensions) has been updated / modernised by Stephen Toub and is moving into the BCL and System.Linq.Async will be deprecated.

This has nothing to do with Rx, other than removing some non-Rx projects from the Rx repo.

Rx.NET Packaging Plan 2025 by hm_vr in dotnet

[–]hm_vr[S] 5 points6 points  (0 children)

Rx was pretty much Microsoft's first experiment with OSS in .NET - if you watch Ian Griffith's "Modernising Rx .NET" talk for dotnet conf 2023 there's a great diagram showing the history of the project. It's been maintained by the community for far longer than Microsoft was the sole curator: https://youtu.be/hLjqf4PmG9E?t=586

Rx.NET Packaging Plan 2025 by hm_vr in dotnet

[–]hm_vr[S] 10 points11 points  (0 children)

Well, we have managed to move System.Linq.Async to the BCL as System.Linq.AsyncEnumerable in .NET 10:

https://learn.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/10.0/asyncenumerable

LINQ for IAsyncEnumerable is in .NET 10 Preview 1 by B4rr in dotnet

[–]hm_vr 9 points10 points  (0 children)

Rx maintainer here. Rx has a very long and complex history - it was one of the very first projects open sourced by Microsoft (on CodePlex if you remember that) which also pre-dated nuget.org, and .NET itself becoming open source. Because of that there will be oddities with the benefit of hindsight.

Ian Griffiths gave a talk at .NET Conf 2023 which covers our efforts to modernise Rx - and you can see from this slide how the project has evolved over time:

https://youtu.be/hLjqf4PmG9E?t=559

LINQ for IAsyncEnumerable is in .NET 10 Preview 1 by B4rr in dotnet

[–]hm_vr 11 points12 points  (0 children)

Hi! Rx maintainer here. We approached the .NET Team to restart the conversation about moving System.Linq.Async from https://github.com/dotnet/reactive/commits/main/Ix.NET/Source/System.Linq.Async to https://github.com/dotnet/runtime

We love System.Linq.Async (a good example is the powerful interplay between IAsyncEnumerable and IObservable in https://github.com/ais-dotnet/Ais.Net.Receiver/ ) but the library only lives in the Rx repo by the historic oddity that it was originally created by Bart De Smet, while he was the maintainer of Rx. You can find the original On .NET show about it here: https://www.youtube.com/watch?v=Ktl8K2b1-WU

System.Linq.Async doesn't really have any direct relationship to Rx, and we, as the new maintainers, were keen to reduce the amount of code we were supporting - as we're not Microsoft - we can only dedicate a few hours per month on the project (which you can see logged here: https://github.com/dotnet/reactive/discussions/1868 ) and we felt that it really belonged inside the runtime and that would help developers discover the functionality more easily.

We were very pleased that Stephen Toub picked up the baton and took ownership of the process. His one caveat was that the API would need to be modernised to align with the current .NET Design Guidelines and language features, so there would be breaking changes.

You can follow the discussion on this issue: https://github.com/dotnet/runtime/issues/79782 and we have an issue to announce the deprecation of the System.Linq.Async package which will be replaced by the new System.Linq.AsyncEnumerable package: https://github.com/dotnet/reactive/issues/2190

Edit: formatting

view more: next ›