This is cool.

As far as I can tell, incremental the library aims to solve the problem of partially hydrating a computation graph when source data is altered. This approach is similar to the one pursued by (well designed) build systems and is common in the FP world. [2] This has many use cases and is very cool.

In addition, in the sphere of incremental computation, there exists Differential Dataflow, Timely Dataflow (adjacent), and DBSP. Systems like Feldera are built on DBSP. Materialize is lead by some DD guys.

Personally, I am pursuing an orthogonal approach specifically for the problem of financial data and financial workloads, There exists huge, very important problems to solve! [1]

[1] https://modolap.com

[2] Signals And Threads episode on the subject https://signalsandthreads.com/build-systems/

▲

valzam 8 hours ago | parent | next [-]

> https://modolap.com

Redirect to a 2k USD stripe payment with no explanation when clicking on the main callout button is a pretty baller move.

▲

ronfriedhaber 8 hours ago | parent [-]

One man's baller is another man's insufficiently baller.

Email me for details, pricing & installations, or your target use case, would love to talk. In addition, if you have any feedback.

ron at modolap dot com

▲

foltik 4 hours ago | parent [-]

Your site has a bunch of marketing copy, trademark symbols, and a link to pay you $2k/mo, but zero technical detail and is broken on mobile. It gives vibe coded.

The benchmark of 2m black-scholes evals/sec is meaningless without additional context. Also seems a couple orders of magnitude slower than what I’d expect even for a single core. What exact transformations are being done, and what’s the throughput in GB/sec? Is it multi threaded? Benchmark against the equivalent query in kdb+ and ClickHouse?

	▲	ronfriedhaber 3 hours ago \| parent [-]
		> is broken on mobile Not true as of last deployment. > but zero technical detail What additional technical detail would you be interested in? > Also seems a couple orders of magnitude slower than what I’d expect even for a single core. 1) it's more than 2m/s on a MacBook AIR 2) Most of the latency is networking. This was a preliminary setup with a client / server over websockets where the book of 1m contracts combination of (strike, exp_date). Each insert only after a corresponding query has been returned (over the wire) from the previous insert. I can agree the eval isn't great; as in, the throughput is much higher. > What exact transformations are being done This is provided in the blog post.

▲

hantusk 2 hours ago | parent | prev [-]

Check out https://github.com/ila/openivm which implements a very large scope of aggregations as incremental operations in an SQL-to-SQL compiler, and extension for duckdb that automatically maintains a materialized view