reactor-core
differential-dataflow
reactor-core | differential-dataflow | |
---|---|---|
21 | 14 | |
4,813 | 2,473 | |
0.3% | 0.8% | |
9.4 | 8.3 | |
8 days ago | 6 days ago | |
Java | Rust | |
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.
reactor-core
-
Is it wrong to use "try-catch" inside a reactive stream operator (project reactor)?
I was exploring reactive streams with project reactor and I encountered a use case where I needed to skip to the next event if an error occurred during the processing of the current event (e.g. deserialization issue).
-
Modern Async Primitives on iOS, Android, and the Web
Kotlin also has a construct for asynchronous collections/streams. Kotlin's version of AsyncSequence is called a Flow. Just as Swift's AsyncSequence builds upon prior experience with RxSwift and Combine, Kotlin's Flow APIs build upon earlier stream/collection APIs in the JVM ecosystem: Java's RxJava, Java8 Streams, Project Reactor, and Scala's Akka.
-
Alternatives to scala FP
Java's projectreactor.io ? It is widely used in Java world, see Spring WebFlux.
-
Hydroflow: Dataflow Runtime in Rust
I guess more a closer comparison would be with the Project Reactor https://projectreactor.io/ which is also a low level framework for data processing.
-
Reactive Backend Applications with Spring Boot, Kotlin and Coroutines (Part 1)
Spring Framework is one of the most popular choices for web applications. It comes with a great ecosystem, tooling, and support. Spring applications are mainly written in Java. While they can serve quite well in many different domains and use cases, they may not be a good fit for modern-day applications which require low-latency and high-throughput. This is where the reactive programming paradigm could help because the paradigm is designed to address these issues by its non-blocking nature. Spring already supports reactive programming via Project Reactor.
-
Brief Intro to Reactive Streams with Project Reactor
The reactive streams API provides the specification for non-blocking async streams processing with back pressure mechanism, and Project Reactor is an implementation written in java.
- Angular for Junior Developers: Promises vs Observables
-
How much of real world programming involves using containers and for loops?
https://projectreactor.io/ https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.html https://rxjs.dev/ https://developer.android.com/kotlin/coroutines https://developer.apple.com/documentation/combine
- Spring Reactor
-
Reactor bad, Loom good - but how will the landscape shape out?
With respect to Loom, it could be much easier for synchronous and reactive code to interoperate using schedulers that take advantage of Loom. The impact of Loom on Project Reactor was discussed in #3084, you might find it interesting.
differential-dataflow
-
We Built a Streaming SQL Engine
Some recent solutions to this problem include Differential Dataflow and Materialize. It would be neat if postgres adopted something similar for live-updating materialized views.
https://github.com/timelydataflow/differential-dataflow
https://materialize.com/
-
Hydroflow: Dataflow Runtime in Rust
I'm looking for this but can't find it, how does this project compare to differential dataflow?
As a sibling commenter mentioned, it's built on timely dataflow (which is lower-level), but that already has differential dataflow[0] built on top of it by the same authors.
How do they differ?
[0]: https://github.com/TimelyDataflow/differential-dataflow
- Using Rust to write a Data Pipeline. Thoughts. Musings.
- PlanetScale Boost
- Program Synthesis is Possible (2018)
-
Convex vs. Firebase
hi! sujay from convex here. I remember reading about your "reverse query engine" when we were getting started last year and really liking that framing of the broadcast problem here.
as james mentions, we entirely re-run the javascript function whenever we detect any of its inputs change. incrementality at this layer would be very difficult, since we're dealing with a general purpose programming language. also, since we fully sandbox and determinize these javascript "queries," the majority of the cost is in accessing the database.
eventually, I'd like to explore "reverse query execution" on the boundary between javascript and the underlying data using an approach like differential dataflow [1]. the materialize folks [2] have made a lot of progress applying it for OLAP and readyset [3] is using similar techniques for OLTP.
[1] https://github.com/TimelyDataflow/differential-dataflow
[2] https://materialize.com/
[3] https://readyset.io/
-
Announcing avalanche 0.1, a React- and Svelte-inspired GUI library
differential dataflow which is used to power materialize db
-
Differential Datalog
It's partially inspired by Linq, so the similarity you see is expected.
It's not really arbitrary structures so much, though you're mostly free in what record type you use in a relation (structs and tagged enums are typical, though).
The incremental part is that you can feed it changes to the input (additions/retractions of facts) and get changes to the outputs back with low latency (you can alternatively just use it to keep an index up-to-date, where you can quickly look up based on a key (like a materialized view in SQL)).
This [0] section in the readme of the underlying incremental dataflow framework may help get the concept across, but feel free to follow up if you're still not seeing the incrementality.
[0]: https://github.com/TimelyDataflow/differential-dataflow#an-e...
- Dbt and Materialize
- Materialized view questions
What are some alternatives?
Reactive Streams - Reactive Streams Specification for the JVM
ballista - Distributed compute platform implemented in Rust, and powered by Apache Arrow.
RxKotlin - RxJava bindings for Kotlin
materialize - The data warehouse for operational workloads.
RxJava - RxJava – Reactive Extensions for the JVM – a library for composing asynchronous and event-based programs using observable sequences for the Java VM.
reflow - A language and runtime for distributed, incremental data processing in the cloud
reactor-kotlin-extensions
differential-datalog - DDlog is a programming language for incremental computation. It is well suited for writing programs that continuously update their output in response to input changes. A DDlog programmer does not write incremental algorithms; instead they specify the desired input-output mapping in a declarative manner.
redux-kotlin - Predictable state container for Kotlin apps
timely-dataflow - A modular implementation of timely dataflow in Rust
Async Http Client - Asynchronous Http and WebSocket Client library for Java
clj-3df - Clojure(Script) client for Declarative Dataflow.