foam VS differential-dataflow

Source: (1) A personal knowledge management and sharing system for VSCode - Foam. https://foambubble.github.io/foam/. (2) A personal knowledge management and sharing system for VSCode. https://github.com/foambubble/foam. (3) Loam - Visual Studio Marketplace. https://marketplace.visualstudio.com/items?itemName=ciceroisback.loam.

You should have a look at Foam: https://github.com/foambubble/foam

I started using Foam[0] a few years ago, but the more I used it, the more I dropped all the tedious bits, and it became nothing more than a big, evolving markdown repo.

When I switched from vscode (back) to vim, it has worked as well or better than it did before. I follow my own rules. I like the Zettelkasten idea of one idea per card, but if I put more related things in the same .md file, that's OK. I didn't like the flat directory structure, and so I have dirs organized by category. My /bar directory is inside my /cooking directory, and for whatever reason, that makes sense to me. Ripgrep doesn't care, and I always find what I'm looking for.

This markdown hierarchy, that still lives in a repo called "foam", has become indispensable to me.

[0] https://github.com/foambubble/foam

Probably use foam https://github.com/foambubble/foam

So I switched to FOAM and it's just clean & organized markdown files in a git repo. Self host a code server instance and I can reference it without installing something to the work machine.

Recently I started to configure my digital garden. Foam is a good option, Hugo Doks, No Style Please, Git-Wiki, Researcher, Thinkspace, and other themes are good for zetteltasken pages.

I use foam and VSCode and regularly am wow'd with what I am having it do next. I feel I am still just getting started too.

I've wondered about using obsidian with foam as a web editing fallback.

Since the data store is markdown and can be synced with Git, you can already work with an Obsidian vault using Foam in VSCode. I do.

You do need to align some options in each, such as file naming, a header, a particular style of links, and ensure frontmatter behavior. All necessary settings exist.

https://foambubble.github.io/foam/

https://github.com/foambubble/foam/issues/46

This supports basic static file and links functionality, not extended data tools etc., of course.

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