Comment by haolez
3 months ago
On a side note, what tools that leverage Datalog are in use by the HN crowd?
I know that Datomic[0] is very popular. I've also been playing with Clingo[1] lately.
3 months ago
On a side note, what tools that leverage Datalog are in use by the HN crowd?
I know that Datomic[0] is very popular. I've also been playing with Clingo[1] lately.
Check out CozoDB, the embedded datalog-queried hybrid relational+vector+graph database written in Rust: https://www.cozodb.org/
I used it in a toy application and it was awesome.
This appears to be a dream database from the future.
It seems like the project has been abandoned? Last commit a year ago.
Fair point but what if it's just really solid already! :D
Idk, I'm not too worried about that, I'm eager to help out on a project like this if something came up.
Yep, bit of a shame, many nice things in it and interesting to learn from but not active.
I have some local-first/client-side applications using datascript in ClojureScript. Used datahike (FOSS Datomic alternative) some times on the backend too, but mostly tend to use XTDB nowadays, which used to have a Datalog API but I think they removed in favor of SQL-like way instead, which was kind of a shame.
I guess SQL is a requirement if they want to market their technology to normies.
SQL can express Datalog-like queries rather easily using recursive CTE's, and even more so via the recently-added Property Graph Query syntax.
1 reply →
Just gave a talk about this: https://blog.waleedkhan.name/what-if-sql-were-good/
- Recommend Ascent (Rust only, but supports targeting WASM)
- Soufflé: good, but too hard to integrate into existing systems; lots of ergonomic problems in comparison to Ascent (can elaborate)
- CozoDB: really cool but seems to be abandoned
- Logica: have not tried it yet
Would like to hear about the ergonomic problems you have with souffle. We integrate it into our rust tools quite well, and generate typesafe rust bindings to our souffle programs, allowing us to insert facts and iterate over outputs.
It's quite possible that I have different, smaller-scale problems than you have! So my feedback might not be as relevant
I wrote detailed commentary here: https://github.com/s-arash/ascent/discussions/72
Re Rust bindings and your specific comment:
- Deploying Soufflé and doing FFI is much more difficult for me in practice, just in terms of the overhead to set up a working build. (I'm not going to be able to justify setting up a Soufflé ruleset for Bazel, and then adding Rust-Soufflé binding generation, etc. at my workplace.)
- User-defined functors, or integrating normal data structures/functions/libraries into your Soufflé program, seems painful. If you're doing integrations with random existing systems, then reducing the friction here is essential. (In slide 16 of the talk, you can see how I embedded a constructive `Trace` type and a `GlobSet` into an actual Ascent value+lattice.)
- On the other hand, you might need Soufflé's component system for structuring larger programs whereas I might not (see above GitHub discussion).
Non-specifically:
- Several features like generative clauses, user-defined aggregations, lattices, etc. seem convenient in practice.
- I had worse performance with Soufflé than Ascent for my program for some query-planning reason that I couldn't figure out. I don't really know why; see https://github.com/souffle-lang/souffle/discussions/2557
3 replies →
For a while the Rust compiler's borrow checker "Polonius" was implemented with datalog using the `datafrog` engine. However, it appears to me that the in-tree version of polonius is moving away from datafrog (not enough of a rustc expert to say for sure which version of the borrow checker engine is in use)
CodeQL compiles to the Souffle datalog engine and I use it for static analysis. I've also used ascent for a few random side projects in Rust which is very convenient.