iterlib VS kiss-orm

I wrote such a C++ implementation during my days at Facebook around 8 years ago:

https://engineering.fb.com/2016/03/18/data-infrastructure/dr...

There is an example under "Functional programming primitives".

It was a C++ implementation that fell victim to Greenspun's 10th rule. So I wrote a specification for it, first in Clojure and then in python.

The C++ execution engine is open source:

https://github.com/facebookarchive/iterlib/

Main problems writing such code:

* The output of SQL is generally flat. GraphQL makes it nested, but doesn't support all the operators SQL does natively.

I found this: https://github.com/Seb-C/kiss-orm

I totally agree with the views of the author. That is basically why I started to build an ORM that does not include a query builder. Best of both worlds.

Now the design was far from easy, and keeping things reasonably simple without abstracting the SQL part was my biggest challenge. And this would not have been possible without the template-string tagging feature of modern JS, so it wouldn't be doable for many other languages.

https://github.com/Seb-C/kiss-orm