clingo VS cozo

One of the easiest to get started on Datalog in my opinion is really clingo https://potassco.org/clingo/ , which can be pip installed and has python bindings. Answer Set Programming goes beyond datalog, but it holds datalog semantics as a sublanguage. It is unfortunate this is not well advertised.

```

Love this article and the push to build awareness of what modern SAT solvers can do.

The thing it misses, though, is that there are higher level abstractions that are far more accessible than SAT. If I were teaching a course on this, I would start with either Answer Set Programming or Satisfiability Modulo Theories (SMT). The most widely used solvers for those are clingo [0] and Z3 [1]:

With ASP, you write in a much clearer Prolog-like syntax that does not require nearly as much encoding effort as your typical SAT problem. Z3 is similar -- you can code up problems in a simple Python API, or write them in the smtlib language.

Both of these make it easy to add various types of optimization, constraints, etc. to your problem, and they're much better as modeling languages than straight SAT. Underneath, they have solvers that leverage all the modern CDCL tricks.

We wrote up a paper [2] on how to formulate a modern dependency solver in ASP; it's helped tremendously for adding new types of features like options, variants, and complex compiler/arch dependencies to Spack [3]. You could not get good solutions to some of these problems without a capable and expressive solver.

[0] https://github.com/potassco/clingo

Answer Set Programming is an incredibly powerful tool to declaratively solve combinatorial problems. Clingo is one of the best open source implementations in my opinion: https://github.com/potassco/clingo

Any thoughts on how your project will compare to CozoDB?

https://github.com/cozodb/cozo

I can figure parts of it out from https://github.com/cozodb/cozo/blob/main/cozo-core/tests/air_routes.rs which is enough to get started

I've been keeping an eye on https://github.com/cozodb/cozo which is pretty close to something I've wanted, a sqlite version of datalog/datomic.

Finally, the one product I was extremely impressed with and felt was genuinely impressive as a database in general was cozodb.

Take a look at cozodb. It meets most of your goals and I've been really enjoying using it. It might give you some inspiration or something to contribute to.

Sure. They're called 'partials' sometimes. Useful if you want to rerender just part of a page. This is a pattern used by HTMX, a 'js framework' that accepts fragments of html in an http response and injects it into the page. This is good because it avoids the flash and state loss of a whole page reload. See the HTMX essay on template fragments for a more complete argument [0].

This is a go template for an interactive todos app [1] that I'm experimenting with. The html content of the entire page is present in one template definition which is split into 6 inline {{block}} definitions / "fragments". The page supports 5 interactions indicated by {{define}} definitions, each of which reuse various block fragments relevant to that interaction. I'm in the process of converting it to use embedded cozodb [2] queries which act as a server side data store. The idea here is that the entire 'app', including all html fragments, styles, http requests and responses, db schema, and queries are embedded into this single 100-line file.

[0]: https://htmx.org/essays/template-fragments/

[1]: https://github.com/infogulch/go-htmx/blob/master/templates/t...

[2]: https://github.com/cozodb/cozo

If anyone wants to try a FOSS vector-relational-graph hybrid database for more complicated workloads than simple vector search, here it is: https://github.com/cozodb/cozo/

About the integrated vector search: https://docs.cozodb.org/en/latest/releases/v0.6.html

It also does duplicate detection (Minhash-LSH) and full-text search within the query language itself: https://docs.cozodb.org/en/latest/releases/v0.7.html

HN discussion a few days ago: https://news.ycombinator.com/item?id=35641164

Disclaimer: I wrote it.