dotty-cps-async
Rx.NET
Our great sponsors
dotty-cps-async | Rx.NET | |
---|---|---|
10 | 61 | |
164 | 6,426 | |
- | 1.4% | |
9.4 | 6.6 | |
17 days ago | 15 days ago | |
Scala | C# | |
Apache License 2.0 | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
dotty-cps-async
-
Help a Kotlin convert back into Scala world
Now in scala we have direct mode transformers: dotty-cps-async [https://github.com/rssh/dotty-cps-async] with cps-async-connect [https://github.com/rssh/cps-async-connect ] supports all well-knowm monad stacks, for ZIO also exists ZIO-direct [https://github.com/zio/zio-direct ] , for IO - cats-effect-cps [https://github.com/typelevel/cats-effect-cps ], for kyo [https://github.com/fwbrasil/kyo ] - kyo-direct.
-
dotty-cps-async 0.9.12 is out
dotty-cps-async: https://github.com/rssh/dotty-cps-async
-
The case against Effect Systems (e.g., the IO data type)
Hmm, you can write direct-style code with monad: https://github.com/rssh/dotty-cps-async allows this, exists support libraries exist for near all well-known effect systems: https://github.com/rssh/cps-async-connect, so you can use async/await with IO/ZIO the same as with Future. Although in IO style, any operation that mutates state is async, it's hard to write code where you should place `await` near each line. And it looks like automatic coloring is a too radical change of concepts for most functional programmers. The option to allow using <- in the direct style may be more popular, but this requires changes to the scala core. Another question - are we need effective systems to be present in each program in industrial-style development? Here I agree that mostly no.
- New Scala 3 Codebases
-
Dotty-cps-async 0.9.7 is released.
This is a generic async/await transformer for scala3 which allows using effectful monads in the direct style. URL: (https://github.com/rssh/dotty-cps-async )
-
Language-assisted Flattening
dotty-cps-async [rssh/dotty-cps-async ] with automatic coloring do something very similar in two steps. Automatic coloring defines implicit conversion F[A] => A as x => await(x)(m). The compiler inserts those awaits inside async blocks and then eliminates them later via cps-transform. Exists some limitations which we need to add for effect monads like IO (we don't want run effect twice and don't want to screw semantics of effects by extra memoizing). So, if your language has a possibility to implement effect monads, then you need a possibility to restrict using Flattenable.
Rx.NET
-
Patterns for consuming a throttled/rate limited external APIs?
https://github.com/dotnet/reactive has a lot of different time related extensions for "events". Maybe you'll find something for yourself, if you google for rate limiting with reactive.
-
How can you detect when a user has stopped scrolling with WPF
Install Reactive Extensions: https://github.com/dotnet/reactive
-
MVVM Question: How do you manage the interaction between Model and ViewModel?
I'd use a dedicated event bus based on Reactive Extensions or MediatR to publish domain events from your domain services. This probably doesn't solve all your ViewModel update problems as is, maybe you need to revise the granularity (maybe you can have smaller ViewModels that refresh single property that exposes the Model) and lifespan (sometimes you can create a ViewModel, make it perform it's task and then discard it completely) of your ViewModels.
Typically if you want to notify interested parties (ViewModels in case of WPF) of Model changes you'd use some kind of pub-sub mechanism like Reactive Extensions or MediatR. Your ViewModel can subscribe to an event bus of some kind (either standalone or maybe exposed by an Aggregate if you follow DDD), your domain logic (which should be located in Model layer, not in ViewModel layer: Service, Repository, DDD Aggregate or whatever you'd like to call it) will then do something useful with your Model and publish the corresponding event to the event bus.
-
Async Methods after setting a property.
If you're finding yourself in a situation where you need to turn this behavior into a pattern because there are a lot of View Models that need to execute async business logic in response to some changes, I'd go with something like MediatR or Reactive Extensions. The idea is, again, that some other, probably business-level, component listens to changes in a decoupled way (that means it doesn't subscribe directly to your View Model, but to an event bus instead). View Model publishes change events to the event bus, and business-component reacts to these events by executing the business logic.
-
System.Reactive v6.0.0-preview.1 available on NuGet
We'd really appreciate if it consumers of the library could update and provide any issues / bugs via the GitHub repo: https://github.com/dotnet/reactive/issues
-
Brett Slatkin: Why am I building a new functional programming language?
The thing that really irks me is that the generator pattern doesn't have to be an OO-first feature. Observable streams[1] work with the same basic foundation and those are awesome for FP.
-
What Are Signals?
> I’m not sure what you mean by "Rx" in this context.
From “reactive extensions”, a proper name for a family of libraries[1] (RxJava, Rx.NET, RxJS), AFAICT one of the first attempted implementations of mature FRP ideas in the imperative world and one messy enough that it took React for anything similar to reënter the mainstream.
Compare the enthusiastic HN reception of “Deprecating the observer pattern” in 2011[2], mostly from people who heard of FRP in the functional setting, and the vitriol it received in 2018[3], from people for whom FRP came to mean Rx (and similarly confused things like Bacon.js). It is this vitriol that I meant to preemptively redirect by the mention of FRP ≠ Rx, so if you’re not aware of this history it’s no big loss to ignore it.
-
I love LINQ and the Entity Framework
If you love LINQ, you'll like Rx.NET even more - iterating over events https://reaqtive.net/blog/2021/05/sequences-linq-rx-reaqtor-part-02-linq Or possibly even OData (LINQ to REST api)
- Just “Discovered” Linq. Now Whole Program is Full of Linq.
What are some alternatives?
Dynamic Data - Reactive collections based on Rx.Net
RxJS - A reactive programming library for JavaScript
ObservableComputations - Cross-platform .NET library for computations whose arguments and results are objects that implement INotifyPropertyChanged and INotifyCollectionChanged (ObservableCollection) interfaces.
duckdb - DuckDB is an in-process SQL OLAP Database Management System
Disruptor-cpp - Port of LMAX Disruptor to C++
MediatR - Simple, unambitious mediator implementation in .NET
language-ext - C# functional language extensions - a base class library for functional programming
redux-phoenix - Restore redux state from previous sessions like a phoenix from ashes.
scala3-example-project - An example sbt project that compiles using Dotty
axios - Promise based HTTP client for the browser and node.js
benchmarks - Latency benchmarks for messaging
cps-async-connect