refset

It's great how the very first SQL query in that paper is still completely valid and runs on countless implementations:

> SELECT NAME FROM EMP WHERE DEPT = 'TOY'

This is how I see things also. Clojure is extremely practical and naturally attracts people that want to ship products.

The "Figma OSS Alternative" post that's also on the HN homepage right now doesn't mention Clojure anywhere (no comments about it either!), but Penpot is clearly also yet another app successfully shipped using Clojure: https://github.com/penpot/penpot

Codapi looks very slick! It's great that you kept everything generic enough to support many different backend use cases.

Coincidentally my colleagues recently built a custom version of almost this exact same interactive UX for writing SQL tutorials: https://docs.xtdb.com/tutorials/immutability-walkthrough/par...

If only you had launched sooner :)

Considering the functionality on offer the service does look particularly easy to work with, even though there's still a notion of a stateful cluster with per-node sizing & pricing. Perhaps the MemoryDB team will offer something more 'serverless' eventually.

Anything that helps turn RESP into more of a commodity protocol seems like a good thing in the long run. It seems to be simple enough that workloads can legitimately migrate around and users can vote with their wallets for whoever operates the most secure/available/portable(OSS) platform. By contrast SQL tech is in a far more precarious state.

If nothing else, MemoryDB demonstrates that Valkey could be extended with much richer durability/HA guarantees.

Relevant context & reading:

> for most of the history of sql we did not know how to translate it to relational algebra, and now that we do know most databases still don't do it.

https://www.scattered-thoughts.net/writing/unexplanations-sq...

> None of this could be expressed in the original relational algebra, and once you add it all it's not obvious we should even still be calling this an algebra, let alone granting it any mathematical mystique. I'd settle for calling it the 'sql calculus'. Or 'the algebra formerly known as relational'.

> It is still a reasonably good compiler IR though, and that's still the most useful way of thinking about it.

https://www.scattered-thoughts.net/writing/unexplanations-re...

How about as a motivational aid and means of verifying that your code has compiled: https://squint-cljs.github.io/squint/

For analytical queries note that you really have to learn how to express the queries efficiently with Postgres - unfortunately the optimizer is still missing lots of tricks found in more sophisticated engines [0][1][2]. JIT compilation alone can't get close to making up for those gaps.

[0] https://pganalyze.com/blog/5mins-postgres-optimize-subquerie...

[1] https://duckdb.org/2023/05/26/correlated-subqueries-in-sql.h...

[2] "Unnesting Arbitrary Queries" https://cs.emis.de/LNI/Proceedings/Proceedings241/383.pdf

Shameless plug, but XTDB v2 is being built for low-latency bitemporal queries over columnar storage and might be applicable: https://docs.xtdb.com/quickstart/query-the-past.html

We've not been developing v2 with ML feature serving in mind so far, but I would love to speak with anyone interested in this use case and figure out where the gaps are.

> Von Neumann was still deeply involved in hydrogen bomb development beyond simply developing the prerequisite plutonium implosion bomb

This. https://en.wikipedia.org/wiki/John_von_Neumann

> In 1955, von Neumann became a commissioner of the Atomic Energy Commission (AEC)

> He used this position to further the production of compact hydrogen bombs suitable for intercontinental ballistic missile (ICBM) delivery

> He was adamant that H-bombs delivered deep into enemy territory by an ICBM would be the most effective weapon possible

It seems much of his life was dedicated to applying Game Theory.

Looks nice! I would suggest to pointing users to a small demo csv file and query that can be quickly loaded/pasted to see it working. Or even have a "Load example CSV and query" button.

I stumbled on this after realising that Mark Burgess, who created CFEngine, is also the author of this other recent HN post on "Using Promise Theory to solve the distributed consensus problem" [0] (from the same blog).

[0] https://news.ycombinator.com/item?id=39676493

The actual ISO standard falls well short of being useful/sufficient to anyone who isn't an incumbent player. It's effectively a moat and therefore a direct impediment to competition from teams who have novel technical ideas but don't have access to significant capital - building a SQL implementation is a long, expensive journey. This is why many startups resort to building Postgres extensions, or using Calcite or DataFusion.

If SQL weren't so (needlessly) complex we would see much more competition across the database space.

> a join is a communication between components

Makes me wonder just how far people have pushed Foreign Data Wrappers in practice.

Which is fine when everything is handcrafted and human-scale, but as soon as you start going down the path of machine generated SQL (both the generation and analysis thereof) the tax is non-trivial.

Handcrafting JSON is undoubtedly always a pain, but the idea with XTQL is rather that it can be easily generated from any regular programming language.

> I would actively avoid utilizing any query language where I have to count brackets

That's really an editor/tooling problem, solvable in many ways, but I guess a Python-like/Parinfer approach would be your preference? (where whitespace/indentation is significant)

> I don’t understand how there hasn’t been more innovation in this space

I think it's simply that most businesses and investors don't register SQL as having any real problems, and especially now with a resurgent interest in SQL the idea of attempting anything novel feels too risky.

Shameless plug of one recent attempt to offer something different: XTQL https://docs.xtdb.com/intro/what-is-xtql.html

> Lest you think is just one weird corner of the sql spec, I found this helpful diagram explaining how the scoping rules work (from Neumann and Leis, 2023)

It's an excellent diagram, it really conveys the dissonance. Incidentally I interviewed Viktor Leis on a podcast last week about the paper where it's from: https://juxt.pro/blog/sane-query-languages-podcast/

A lot of people seem to believe that LLMs or other ML methods can overcome the complexity challenges of generating SQL accurately, but I'm yet to be convinced that a database-powered AI revolution can happen without somehow bypassing SQL.

> Btw, if you have a reference to the creation of Datalog older than the one I linked to, please share it

1982 was as far as I got last time I went digging: https://news.ycombinator.com/item?id=34819400

> don't have to have two separate worlds for queries and other logic

That's definitely the dream. Another point along that spectrum (from the author of Apache Calcite): https://github.com/hydromatic/morel

But only if the data is valuable enough to cover the (much) higher costs that come with those assumptions.

There's more potential applicability/overlap for columnar relational engines (vs. row stores) - this 2023 paper offers some useful background: https://arxiv.org/pdf/2308.08702.pdf

To add to this description, the Prolog-derived syntactic core of Datalog (the Horn clauses and facts) can be viewed as a combination of "unification" and mutually recursive rules to find a fixpoint over your data+query. It's essentially like solving simultaneous equations.

The Prolog-derived syntax is routinely extended because the core is typically too simplistic/inexpressive to be directly useful, e.g. see https://www.fdi.ucm.es/profesor/fernan/des/html/manual/manua...

I fully agree with what Prime says at the end - Joran has really set a new bar here for all future database presentations.

Hearing that the entire TigerBeetle domain logic lives in a single file [0] (and is intended to be pluggable for other OLTP use cases!) makes it 1000% more tempting to spend the weekend getting up to speed with Zig.

[0] https://github.com/tigerbeetle/tigerbeetle/blob/main/src/sta...

The previous interview on this Clojure-in-Banking theme (featuring Griffin [0]) attracted quite a lot of discussion here before: https://news.ycombinator.com/item?id=37313183

[0] https://griffin.com

Agreed - the main reason I switched to KDE from Gnome was so I could have a vertical taskbar.

> I much prefer when you start with a big-blob of joins to define the data source before getting into the applied operations

That's essentially the model we've chosen for XTQL, with the addition of a logic var unification scope for even more concise joins: https://docs.xtdb.com/intro/what-is-xtql#unify

Also, anyone interested in this post-SQL space would probably enjoy this recent paper: https://www.cidrdb.org/cidr2024/papers/p48-neumann.pdf

One such effort: https://github.com/omnigres/omnigres

"Programming with hand tools" (Tim Ewald, Clojure Conj 2013) is a very memorable talk on this theme: https://youtu.be/ShEez0JkOFw