differential-dataflow VS faust

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/

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

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/

differential dataflow which is used to power materialize db

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...

Glicol looks very cool! Also check out Faust if you haven't (https://faust.grame.fr), another FP sound programming language.

The linked (https://github.com/grame-cncm/faust) looks reasonable to me.

Chata probably needs to work out roughly what the semantics of the language should be. Its good to know what the library support is intended to be as that informs language design (assuming the library is to be implemented in chata anyway). Quite a lot of this page is about syntax.

There are some design decisions that have deep impact on programming languages. Reflection, mutation, memory management, control flow, concurrency. There are some implementation choices that end up constraining the language spec - python seems full of these.

Echoing p4bl0, implementing the language will change the spec. Writing a spec up front might be an interesting exercise anyway. I'd encourage doing both at the same time - sometimes describe what a feature should be and then implement it, sometimes implement something as best you can and then describe what you've got.

Implementation language will affect how long it takes to get something working, how good the thing will be and what you'll think about along the way. The usual guidance is to write in something familiar to you, ideally with pattern matching as compilers do a lot of DAG transforms.

- I'd say that writing a language in C took me ages and forced me to really carefully think through the data representation.

- Writing one in lua took very little time but the implementation was shaky, probably because it let me handwave a lot of the details.

- Writing a language in itself, from a baseline of not really having anything working, makes for very confusing debugging and (eventually) a totally clear understanding of the language semantics.

Good luck with the project.

Faust integration would be awesome: https://faust.grame.fr Then again we have MaxMSP, so in the end it feels kind of redundant

Csound is extremely powerful, but my favorite thing in this vein these days is Faust:

https://faust.grame.fr/

It's a functional language with a nice way of generating diagrams of DSP algorithms, but its big killer feature for me is its language bindings, which include C, C++, Cmajor, Codebox, CSharp, DLang, Java, JAX, Julia, JSFX, "old" C++, Rust, VHDL, and WebAssembly (wast/wasm) out of the box.

Have a look at FAUST as well: https://faust.grame.fr/

Once you have an idea of basic programming practice, you need to learn some DSP programming. One of the better tools for this is Faust https://faust.grame.fr/ , bear in mind this is a functional programming language, and has very different syntax to C++, but the same principles apply.