Datalog is great for representing authorization rules. Check out Biscuits, which are auth tokens with Datalog embedded in them. This article is what made it 'click' for me: <a href="https://www.clever-cloud.com/blog/engineering/2021/04/15/biscuit-tutorial/" rel="nofollow">https://www.clever-cloud.com/blog/engineering/2021/04/15/bis...</a><p>I actually thought that Datalog was so cool that I went to learn Prolog and it completely changed the way I think about programming. Highly recommend trying out logic programming if you haven't before.
In the last few months the mention of Datalog has increased, I wondered how it differed from graph databases and found a clear answer in SO [1]. I am not an incumbent but found graph databases and clause approaches interesting.<p>[1] <a href="https://stackoverflow.com/questions/29192927/a-graph-db-vs-a-prolog-or-minikanren" rel="nofollow">https://stackoverflow.com/questions/29192927/a-graph-db-vs-a...</a> (2015)
ICYMI, there's an excellent interactive introduction to `datalog` that's referenced in the article's references.[0]<p>Last time I used `datalog` was years ago, I was developing an internal interactive tool that was used to compare different approaches to solving a certain problem at my employer. I used `datascript`[1] by way of clojurescript to store all experiment data and then interrogated the `datascript` DB via `datalog`. This is something I always remember fondly.<p>[0] <a href="https://www.learndatalogtoday.org/" rel="nofollow">https://www.learndatalogtoday.org/</a>
[1] <a href="https://github.com/tonsky/datascript">https://github.com/tonsky/datascript</a>
As mentioned in the article, Datomic is a database that uses Datalog as its query language:<p><a href="https://docs.datomic.com/on-prem/query/query.html#why-datalog" rel="nofollow">https://docs.datomic.com/on-prem/query/query.html#why-datalo...</a><p>(Some ten years ago worked at a startup that used Datomic. It seemed to work great, although the only queries I ever needed to add to the system were simple copy-paste hacks of existing ones, so I never got to dive into Datalog.)
A bit related, just stumbled upon Flix, a functional JVM language with Datalog contraints and (somewhat?) Go-like concurrency:<p><a href="https://flix.dev" rel="nofollow">https://flix.dev</a><p>HN Thread from 8 months ago: <a href="https://news.ycombinator.com/item?id=31448889" rel="nofollow">https://news.ycombinator.com/item?id=31448889</a>
So I struggled with this.<p>I guess the intention is to be better than SQL but then I was left with "under which circumstances?".<p>With that question in mind I didn't feel the article addressed the issue.<p>The author might do better to think in terms of "what burning problem are we trying to fix and how did we fix it".
I’ve been using Prolog a bunch recently, and also embedded and extended MicroKanren in a project. Something I came to appreciate was that Prolog’s depth-first search, and Kanren’s lazy stream approach are good with memory even when generating/searching through infinite solutions. It is my understanding that Datalog, on the other hand, will iteratively expand a set of data. Isn’t this a problem?
Whatever language this is... This is not datalog. This looks like a particular implementation of datalog in closure.<p>Actual datalog looks like prolog.
I created a datalog engine a few years back called Dr. Lojekyll: <a href="https://www.petergoodman.me/docs/dr-lojekyll.pdf" rel="nofollow">https://www.petergoodman.me/docs/dr-lojekyll.pdf</a><p>It was pretty cool; you could stream in new facts to it over time and it would incrementally and differentially update itself. The key idea was that I wanted the introduction of ground facts to be messages that the database reads (e.g. off of a message bus), and I wanted the database to be able to publish its conclusions onto the same or other message buses. I also wanted to be able to delete ground facts, which meant it could publish withdrawals of the prior-published conclusions. A lot of it was inspired by Frank McSherry's work, although I didn't use timely or differential dataflow. In retrospect I probably should have!<p>This particular system isn't used anymore because we made a classic monotonicity mistake by making it the brain of a distributed system, and then having it publish and receive messages with a bunch of microservices. The internal consistency model of the datalog engine didn't extend out to the microservices, and the possibility of feedback loops in the system meant that the whole thing could lie to itself and diverge uncontrollably! Despite this particular application of the engine being a failure, the engine itself worked quite well and I hope to one day return to datalog.<p>I think what a lot of people miss with datalog, and what becomes apparent as you use it more, is just how unpredictable many engines can be with the execution behavior of rules. This is the same problem that you have with a database, where the query planner makes a bad choice or where you lack an index, and so performance is bad. But with datalog, the composition of rules that comes so naturally also tends to compound this issue, resulting in time spent trying to chase down weird performance things and doing spooky re-ordering of your clause bodies to try to appease whatever choices the engine makes.
The problem with Datalog, and Clojure in general are the licenses. Terrible licenses.<p>Everything is about Rich Hickey. Apache 1.0.<p>Now that Nubank basically owns it and there's very little progress or activity as of late, I don't see why one would chose to use Clojure, Datalog etc.<p>Also, a lot of functional programming concepts has been since added to big programming languages like Javascript and hell, even Java has lambdas now.<p>I'm guessing that also hardcore FP people have moved on to Haskell. The ones that like LISP to Racket... and only people tied to the JVM in legacy projects are with Clojure.