The issue with defining schemas in a non-SQL programming language is they always lag behind what the underlying database can do. Sure, your ORM-like framework can define basics like primary keys and maybe uniqueness constraints, but can it define partitioning schemes, compression methods or more advanced constraints?
And then consider that other databases have even more. If you manage your schemas in code then you lose access to all of those, and will eventually need to write SQL anyway.
For queries it isn't such a problem, especially if you have a nice compiler. However, I recently lost faith in SQL wrappers/abstractions. The usual justification was that a lot of developers don't know SQL well, but LLMs are great at it. It's easier for the LLM to write SQL than some less familiar DSL. And SQL was written to be relatively easy to understand, especially if you do things like use CTEs and views correctly it should be possible to factor logic out to make even complex queries understandable.
The question for frameworks like Acadia is really: assuming I am fluent in SQL and know every feature of my database, what does the framework buy me? Because that's the perspective an LLM comes to it with.
There's a lot of benefit in these systems, though there's rough edges and I agree about the basics like PK's and uniqueness.
I've been using Ormin [1] in Nim which works by parsing the SQL tables and uses it to compile time check queries:
# Multiple joins with pagination
let page = query:
select Post(title)
join Person(name) on author == id
join Category(title) on category == id
orderby desc(post.creation)
limit 5 offset 10
I think that's better since defining SQL should be the source-of-truth for the DB and the code. ORM's always ended up causing trouble in my experience.
Things like indexes, defaults, partitions, etc generally aren't expressible in code without a lot of kludges. Then each DB engine have pretty different rules, syntax, etc for tables.
However having the queries compile time checked, type conversions handled, and the nuances between SQL query syntax handled is rather nice. As you mention it's a much easier subset.
Unironcally, yesterday i was vibe-coding a small app for personal use using Django and was quite shocked to discover that Django's orm does not support something as simple as specifying a database schema other than the default "public" one out of the box.
You either have to add options specific from libpq:
Agreed, that's why I chose to implement a simple ORM for my language's multi-platform database library. It has a mandatory 'id' column, for simple updating and deleting, but table creation and complex queries are done in plain SQL.
Isn't SQL already a logical abstraction language over a "physical layer"? I'm not updating indexes or deciding when to flush or fiddling with MVCC when I write SQL
I'm wary of languages that seek to own the database. In particular, the claim "Coexist with SQL" seems a bit suspect given that e.g. sum types have a custom binary encoding, which likely makes them difficult to interop with from other languages. This makes the claimed interop with other languages really more of a temporary stopping point towards full Acadia adoption rather than a viable long-term equilibrium, unless you e.g. eschew using sum types. (I also suspect that trying to natively support sum types can lead to a kind of FP-equivalent of ORMs' impedance mismatch. The ways I model data with relational logic can be pretty different than the ways I model data with algebraic datatypes and I wonder if trying to force fit the latter into the former doesn't lead to the same problems as force fitting objects into relational logic).
This makes the database closer to something that Acadia compiles to, rather than something Acadia sits on top of. From my own developer experience this feels off, because I generally expect the data layer to be king and application code to revolve around that, rather than having data representation created in code and the database created off that (this is why I also dislike things like ORMs).
In general I view databases as usually having more longevity than application code, especially as you accumulate more data over time. For serious production applications, the database often outlives multiple rewrites of the production application.
I suspect though my concerns are overall rather minor. The ergonomics of the language itself seem enjoyable. Acadia seems like it would be great as an embedded DSL. It's a bit unfortunate that it currently seems coupled to creating an HTTP server. I think that Acadia has greater ambitions beyond just the database, as evidenced by creating a binary web connection with frontend Elm code to presumably obviate the need for encode-decode layers. It seems like Acadia is meant to be a stepping stone towards a closer frontend-backend fusion. But I agree with mjaniczek that something like Lamdera seems a better fit for that.
But given how early Acadia is, I'm still very excited for where it goes. What I've listed is surmountable and I also feel that often a closer frontend-backend fusion might be worthwhile.
I think, the reality is SQL being simply to old to coexist with a web app use case. All the nice things that article talks about are not possible to nicely integrate with SQL. Current development is done by either writing SQL by hand or by letting ORMs to autogenerate it. Both feel bad because of how bad SQL is. But there is no other option. I hope https://substrait.io/ will gain traction and will be supported natively by databases
I won't be able to use Acadia at work, and I don't have the risk tolerance to use it for personal projects, but I'm looking forward to seeing how/if this model pays the bills. Can it compete with more liberally licensed code?
I don't see anything special here. Haskell has had stuff like this for more than a decade, Selda is probably the one closest to Acadia: https://valderman.github.io/selda/
Despite their claims, this is not substantially different from ORM platforms in many languages.
This looks reasonably interesting, and Evan is extremely thoughtful about design; I know he’s put a huge amount of work into this.
Personally, I’d be very cautious about adopting closed-source software with such a restrictive license as part of an application, especially given the context of Elm’s trajectory. When Elm went through breaking changes or regressions, or was not worked on publicly for years, users had access to the source and the right to modify it. With Acadia’s licensing, you’d be stranded.
On the other hand, with Elm there was no correlation between adoption and funding for development. With Acadia, he's trying a different funding model, so that might mean better support for both Acadia and Elm.
The Elm project forked into a bunch of different Elms because Evan basically abandoned / killed it. Then he got more interested with this project. What’s to say that won’t happen again?
I think it's fair to say there are other ways to interpret what happened with Elm. What if Evan stopped working on it because he needed to make a living and working on Elm wasn't going to achieve that? In that case, if working on Acadia will earn him a a living, it seems reasonable to believe he will keep working on it.
> So even if “open core” is a strictly better model, we lack the intuition and experience to feel confident starting there. By thinking of Elm as the “open core” at first, we give ourselves time to learn and flexibility to expand the core later.
That is fair but I think that there’s not a clear thing from Evan we can point to which explains it contributes to the uncertainty in this new project. Makes me feel we should be wary of a repeat. If anything it seems what he learned from his experience with Elm is that the project should not have been open, and his main problem seemed to be community relations. Evan’s reputation precedes him so I’m sure Acadia will be a brilliant technical artifact, but I wouldn’t get burned twice trying to be a member of that community or contributing to it technically.
No, I don't know Evan and have never personally interacted with him. I'm wary of BDFLs because you can invest in a tool and then that time and energy is wasted if the wind changes.
I would make the larger point that I do not like my software to depend on any software with a bus factor of one that I can't control. Elm had this problem and Acadia has it too.
As a programming language? Sure. As a way to work with relational data? It may be my favorite "language" across all domains because of the terse beauty. I am a self-taught, no CS coder but SQL is the one place where I feel like I get all the math I should know.
An opinionated, possibly hot take would be to call SQL "A more elegant weapon of a civilized age".
Maybe so, but my father in law, who is a salesman and knows nothing about computers and programming still knows SQL.
SQL is a horrible language in the same way Excel is -- programmers hate it but the what makes it a horrible programming language to developers is what makes it accessible to non programmers.
Having reusable functions and pipelines compiling to SQL sounds amazing. (EDIT: and sum types!) Will want to try this out on some side project later.
Although for my Elm + backend needs I feel like I still prefer Lamdera: https://dashboard.lamdera.app/ - WebSocket communication and being able to push new data to clients immediately instead of juggling HTTP endpoints and the client having to pull/refresh. `sendToBackend`, `sendToFrontend`, `broadcast` are a great primitive.
Reading this, I mistook it for a slightly different idea: using these functional languages directly inside the database process, avoiding SQL altogether.
I've wanted to try that out with e.g. Roc and a reimplementation of SQLite's on-disk format. (Of course, that's a non-starter for production use, but it could be an interesting experiment to see what that programming model was like.) The database would become kind of like a library you use to build your tables and queries with.
Also, thank you for calling it a 1+n query, not an n+1 query ;)
1. An Elm-like programming language that lives in .db files
2. A compiler from this language to strongly-typed database procedures in a target backend language
This has more in common with a semantic layer than an ORM.
What you gain is a shared language that connects the table definitions (say a SQL migrations folder) and your API language (often handwritten SQL). This can be type checked and optimized for you.
But for me the big question is what functionality do you lose? Can I express everything that PostgreSQL can?
Looks very nice.
Last year I took up rust, coming from c++, and some of the modern features rust brings are just so nice to have (even something as simple as not having to forward declare a class).
This year I started working with postgres and you just can't help but notice how sql is coming from the c-Era of programming. Having better and more modern ways to express my queries would be great to improve correctness and performance.
> …can't help but notice how sql is coming from the c-Era of programming. Having … more modern ways to express my queries would be great to improve correctness …
SQL is based in pure mathematics: set theory, relational algebra.
The process of applying mathematical rigor to your database design to prove correctness is referred to as normalization.
I don’t mind criticisms like “It’s old, yuck”, but criticisms like “it’s not correct” mean you haven’t studied or applied the mathematical underpinnings of sql.
Syntax aside, programmers and mathematicians have a very different view on how things should be done.
Programmers look at data and see opportunities for running a pipeline of transformations (map/filter/...). And they tend to write their SQL like this as well. Or use something like Linq or one of the various pipe syntax SQL extensions.
I would say that this is a major reason why there is this sentiment of "SQL is yucky" by developers. The mental models just don't match.
Data storage and retrieval is a different domain than data processing. SQL is very good at the former, not so great for the latter.
SQL is closer to array programming than the usual imperative implementation of looping (and stream programming like the one in Java and Javascript). A better implementation is functional programming like haskell and clojure (lazy and composition of functions).
I think developers should be able to switch their mental model on the fly according to the current domain instead of getting stuck in the first paradigm they have learned.
I agree with the premises, but the result proposed here doesn't look like anything I would like to use unfortunately. Even just looking at a glance you cannot see what it's doing and what each part means.
Still might be viable, but would be tricky to sell.
> SUBSCRIPTION TERMS
> This license is subscription-based and will remain valid only for the duration of your active subscription. Upon expiration or termination of your subscription:
> a) Your rights to use the Software will cease; b) You must uninstall and stop using the Software; and c) You may lose access to any data or content created with or stored in the Software.
On the other hand, norms in software right now are that suckers build and maintain software for free + "the love of the game should be enough for anyone", so it's shocking when people break the norm.
Anyone else just see a blank page when hitting this link? Maybe it doesn't like Firefox or is doing some sort of JavaScript shinanigans to defeat our AI overlords. I don't have enough coffee yet to debug it.
Hmm. I've skimmed the article. It looks to be another ORM/FRM type thing. There are many issues with such things, but for me the most troubling is this: in most systems (obviously...it depends) you don't want to wind the database around the axle of any one software component or language. Having the data separate from the code, and defined/managed with a language that suits data management is a feature not something to be designed out. My hunch is that people who come up with these "solutions" fail to realize this. They then condemn everyone using their layer to endless hair pulling trying to figure out "what SQL did it make from that?" and "how do I make it do this SQL?".
Yeah, from the post it might even be more limited than Django (python) ever was. For example it allows the user to define its own fields, which was used over a decade ago in libraries to extend Django and provide json support long before it was officially supported.
The issue with defining schemas in a non-SQL programming language is they always lag behind what the underlying database can do. Sure, your ORM-like framework can define basics like primary keys and maybe uniqueness constraints, but can it define partitioning schemes, compression methods or more advanced constraints?
Look at all the features supported here:
https://www.postgresql.org/docs/current/sql-createtable.html
And then consider that other databases have even more. If you manage your schemas in code then you lose access to all of those, and will eventually need to write SQL anyway.
For queries it isn't such a problem, especially if you have a nice compiler. However, I recently lost faith in SQL wrappers/abstractions. The usual justification was that a lot of developers don't know SQL well, but LLMs are great at it. It's easier for the LLM to write SQL than some less familiar DSL. And SQL was written to be relatively easy to understand, especially if you do things like use CTEs and views correctly it should be possible to factor logic out to make even complex queries understandable.
The question for frameworks like Acadia is really: assuming I am fluent in SQL and know every feature of my database, what does the framework buy me? Because that's the perspective an LLM comes to it with.
There's a lot of benefit in these systems, though there's rough edges and I agree about the basics like PK's and uniqueness.
I've been using Ormin [1] in Nim which works by parsing the SQL tables and uses it to compile time check queries:
I think that's better since defining SQL should be the source-of-truth for the DB and the code. ORM's always ended up causing trouble in my experience.Things like indexes, defaults, partitions, etc generally aren't expressible in code without a lot of kludges. Then each DB engine have pretty different rules, syntax, etc for tables.
However having the queries compile time checked, type conversions handled, and the nuances between SQL query syntax handled is rather nice. As you mention it's a much easier subset.
1: https://github.com/Araq/ormin
The point is end to end type safety. Whether that is worth the tradeoff of losing direct developer access to the db primitives is another question.
SQL is end to end type safe.
Which end? This moves one end to reach frontend code
Isn’t sql weakly typed? Or does this depend on the engine?
I agree with end to end type safety but that needs more details to sell what problem its solving. Folks dont buy it for itself
> Look at all the features supported here:
> https://www.postgresql.org/docs/current/sql-createtable.html
Unironcally, yesterday i was vibe-coding a small app for personal use using Django and was quite shocked to discover that Django's orm does not support something as simple as specifying a database schema other than the default "public" one out of the box.
You either have to add options specific from libpq:
Or you have to do it from the postgresql side: It's not ergonomic at all.Agreed, that's why I chose to implement a simple ORM for my language's multi-platform database library. It has a mandatory 'id' column, for simple updating and deleting, but table creation and complex queries are done in plain SQL.
A core idea of the relational model is to seperate the logical model from the physical layer including optimizations, indexes etc.
So it makes sense to only expose the logical model at the ORM layer.
The problem comes if you want to define the database schema through the ORM layer, rather than just represet it.
Isn't SQL already a logical abstraction language over a "physical layer"? I'm not updating indexes or deciding when to flush or fiddling with MVCC when I write SQL
The comment mentioned partioning schemes which is defined using SQL but belongs in the physical layer. Indexes are also defined in SQL.
Agreed with you here. In my experience the best solutions go the opposite way, and parse the SQL in ways that can be used from the application.
https://sqlc.dev/ does this for me. Its been nice!
I'm wary of languages that seek to own the database. In particular, the claim "Coexist with SQL" seems a bit suspect given that e.g. sum types have a custom binary encoding, which likely makes them difficult to interop with from other languages. This makes the claimed interop with other languages really more of a temporary stopping point towards full Acadia adoption rather than a viable long-term equilibrium, unless you e.g. eschew using sum types. (I also suspect that trying to natively support sum types can lead to a kind of FP-equivalent of ORMs' impedance mismatch. The ways I model data with relational logic can be pretty different than the ways I model data with algebraic datatypes and I wonder if trying to force fit the latter into the former doesn't lead to the same problems as force fitting objects into relational logic).
This makes the database closer to something that Acadia compiles to, rather than something Acadia sits on top of. From my own developer experience this feels off, because I generally expect the data layer to be king and application code to revolve around that, rather than having data representation created in code and the database created off that (this is why I also dislike things like ORMs).
In general I view databases as usually having more longevity than application code, especially as you accumulate more data over time. For serious production applications, the database often outlives multiple rewrites of the production application.
I suspect though my concerns are overall rather minor. The ergonomics of the language itself seem enjoyable. Acadia seems like it would be great as an embedded DSL. It's a bit unfortunate that it currently seems coupled to creating an HTTP server. I think that Acadia has greater ambitions beyond just the database, as evidenced by creating a binary web connection with frontend Elm code to presumably obviate the need for encode-decode layers. It seems like Acadia is meant to be a stepping stone towards a closer frontend-backend fusion. But I agree with mjaniczek that something like Lamdera seems a better fit for that.
But given how early Acadia is, I'm still very excited for where it goes. What I've listed is surmountable and I also feel that often a closer frontend-backend fusion might be worthwhile.
I think, the reality is SQL being simply to old to coexist with a web app use case. All the nice things that article talks about are not possible to nicely integrate with SQL. Current development is done by either writing SQL by hand or by letting ORMs to autogenerate it. Both feel bad because of how bad SQL is. But there is no other option. I hope https://substrait.io/ will gain traction and will be supported natively by databases
I'm curious what you meant by the web app use case and why you find SQL bad?
He probably is still drinking the NoSQL koolaid of 2015 :)
I'm actually most excited about the new funding model: https://acadia.engineering/license/faq
I won't be able to use Acadia at work, and I don't have the risk tolerance to use it for personal projects, but I'm looking forward to seeing how/if this model pays the bills. Can it compete with more liberally licensed code?
I don't see anything special here. Haskell has had stuff like this for more than a decade, Selda is probably the one closest to Acadia: https://valderman.github.io/selda/
Despite their claims, this is not substantially different from ORM platforms in many languages.
This looks reasonably interesting, and Evan is extremely thoughtful about design; I know he’s put a huge amount of work into this.
Personally, I’d be very cautious about adopting closed-source software with such a restrictive license as part of an application, especially given the context of Elm’s trajectory. When Elm went through breaking changes or regressions, or was not worked on publicly for years, users had access to the source and the right to modify it. With Acadia’s licensing, you’d be stranded.
On the other hand, with Elm there was no correlation between adoption and funding for development. With Acadia, he's trying a different funding model, so that might mean better support for both Acadia and Elm.
The Elm project forked into a bunch of different Elms because Evan basically abandoned / killed it. Then he got more interested with this project. What’s to say that won’t happen again?
I think it's fair to say there are other ways to interpret what happened with Elm. What if Evan stopped working on it because he needed to make a living and working on Elm wasn't going to achieve that? In that case, if working on Acadia will earn him a a living, it seems reasonable to believe he will keep working on it.
> So even if “open core” is a strictly better model, we lack the intuition and experience to feel confident starting there. By thinking of Elm as the “open core” at first, we give ourselves time to learn and flexibility to expand the core later.
https://acadia.engineering/license/faq
The way I read this, Acadia is an attempt to finance working on both it and Elm.
That is fair but I think that there’s not a clear thing from Evan we can point to which explains it contributes to the uncertainty in this new project. Makes me feel we should be wary of a repeat. If anything it seems what he learned from his experience with Elm is that the project should not have been open, and his main problem seemed to be community relations. Evan’s reputation precedes him so I’m sure Acadia will be a brilliant technical artifact, but I wouldn’t get burned twice trying to be a member of that community or contributing to it technically.
Do you nurse a personal grudge?
No, I don't know Evan and have never personally interacted with him. I'm wary of BDFLs because you can invest in a tool and then that time and energy is wasted if the wind changes.
I would make the larger point that I do not like my software to depend on any software with a bus factor of one that I can't control. Elm had this problem and Acadia has it too.
The bus factor for Elm is currently 2, since Tereza (his Wife) works on both Elm and Acadia.
New functional query language for PostgreSQL and SQLite by Evan Czaplicki the author of Elm
So this is capable of turning a one-liner of SQL into six lines of barely readable code?
It seems that is the price you pay for the power to turn a 600-line nightmare SQL query into 60 lines of barely readable code.
I would like to see that example then.
I’m all for improving on SQL, but this syntax does not even solve the dangling comma issue as far as I can tell from the example.
SQL is a horrible language. I’d gladly program in something composable like Elm.
Agree. Datalog could be a better alternative: https://datalevin.org/docs/preface
Unfortunately Evan removed GROUP BY in 0.19 and left to buy cigarettes.
It'd definitely need a solid team behind this and not just Evan Czaplicki if I were to trust a database with my data.
As a programming language? Sure. As a way to work with relational data? It may be my favorite "language" across all domains because of the terse beauty. I am a self-taught, no CS coder but SQL is the one place where I feel like I get all the math I should know.
An opinionated, possibly hot take would be to call SQL "A more elegant weapon of a civilized age".
Or “the worst query language ever, except for all the alternatives”
Maybe so, but my father in law, who is a salesman and knows nothing about computers and programming still knows SQL.
SQL is a horrible language in the same way Excel is -- programmers hate it but the what makes it a horrible programming language to developers is what makes it accessible to non programmers.
Having reusable functions and pipelines compiling to SQL sounds amazing. (EDIT: and sum types!) Will want to try this out on some side project later.
Although for my Elm + backend needs I feel like I still prefer Lamdera: https://dashboard.lamdera.app/ - WebSocket communication and being able to push new data to clients immediately instead of juggling HTTP endpoints and the client having to pull/refresh. `sendToBackend`, `sendToFrontend`, `broadcast` are a great primitive.
Reading this, I mistook it for a slightly different idea: using these functional languages directly inside the database process, avoiding SQL altogether.
I've wanted to try that out with e.g. Roc and a reimplementation of SQLite's on-disk format. (Of course, that's a non-starter for production use, but it could be an interesting experiment to see what that programming model was like.) The database would become kind of like a library you use to build your tables and queries with.
Also, thank you for calling it a 1+n query, not an n+1 query ;)
It seems like this is a few things:
1. An Elm-like programming language that lives in .db files
2. A compiler from this language to strongly-typed database procedures in a target backend language
This has more in common with a semantic layer than an ORM.
What you gain is a shared language that connects the table definitions (say a SQL migrations folder) and your API language (often handwritten SQL). This can be type checked and optimized for you.
But for me the big question is what functionality do you lose? Can I express everything that PostgreSQL can?
Looks very nice. Last year I took up rust, coming from c++, and some of the modern features rust brings are just so nice to have (even something as simple as not having to forward declare a class).
This year I started working with postgres and you just can't help but notice how sql is coming from the c-Era of programming. Having better and more modern ways to express my queries would be great to improve correctness and performance.
It is older than C. It is based on COBOL era idea of structured English as a computer language. There are better alternatives, e.g. Datalog.
> …can't help but notice how sql is coming from the c-Era of programming. Having … more modern ways to express my queries would be great to improve correctness …
SQL is based in pure mathematics: set theory, relational algebra.
The process of applying mathematical rigor to your database design to prove correctness is referred to as normalization.
I don’t mind criticisms like “It’s old, yuck”, but criticisms like “it’s not correct” mean you haven’t studied or applied the mathematical underpinnings of sql.
Syntax aside, programmers and mathematicians have a very different view on how things should be done.
Programmers look at data and see opportunities for running a pipeline of transformations (map/filter/...). And they tend to write their SQL like this as well. Or use something like Linq or one of the various pipe syntax SQL extensions.
I would say that this is a major reason why there is this sentiment of "SQL is yucky" by developers. The mental models just don't match.
Data storage and retrieval is a different domain than data processing. SQL is very good at the former, not so great for the latter.
SQL is closer to array programming than the usual imperative implementation of looping (and stream programming like the one in Java and Javascript). A better implementation is functional programming like haskell and clojure (lazy and composition of functions).
I think developers should be able to switch their mental model on the fly according to the current domain instead of getting stuck in the first paradigm they have learned.
This isn’t talking about correctness of SQL. It’s talking about correctness of queries.
I was hoping for an alternative to PLSQL or stored procedures. But this isn’t about „Database Programming“, it’s a SQL replacement…
It isn't that bad, at least for those of us that like Ada, and feel at home on SQL Developer.
I agree with the premises, but the result proposed here doesn't look like anything I would like to use unfortunately. Even just looking at a glance you cannot see what it's doing and what each part means.
Oh man. If this lobste.rs comment is correct about the subscription terms then this feels like a really hard pill to swallow: https://lobste.rs/s/ykq7ym/rethinking_database_programming#c...
Still might be viable, but would be tricky to sell.
> SUBSCRIPTION TERMS
> This license is subscription-based and will remain valid only for the duration of your active subscription. Upon expiration or termination of your subscription:
> a) Your rights to use the Software will cease; b) You must uninstall and stop using the Software; and c) You may lose access to any data or content created with or stored in the Software.
On the other hand, norms in software right now are that suckers build and maintain software for free + "the love of the game should be enough for anyone", so it's shocking when people break the norm.
I wonder what a nontrivial multi-table query with joins look like in Acadia?
For columnar databases, I love Vortex' Dtypes which lets you attach semantic context in a logical type to what is essentially compressed Arrow https://docs.vortex.dev/concepts/dtypes#logical-types
Or just let the language be the database like https://en.wikipedia.org/wiki/MUMPS ;)
Needs proper docs
stuff like "The endpoint keyword" just gets a mention on the front page/readme with no further detail
Pretty nice, thanks
Anyone else just see a blank page when hitting this link? Maybe it doesn't like Firefox or is doing some sort of JavaScript shinanigans to defeat our AI overlords. I don't have enough coffee yet to debug it.
Try the Internet Archive's cache: https://web.archive.org/web/20260818090328/https://acadia.en...
Is this at all similar to LINQ in C#? I never used it, but I'm vaguely aware of it being a functional approach to querying an RDBMS.
From what I seen (not an expert). It’s mostly sql with a c# flavor and auto translation to native type.
Hmm. I've skimmed the article. It looks to be another ORM/FRM type thing. There are many issues with such things, but for me the most troubling is this: in most systems (obviously...it depends) you don't want to wind the database around the axle of any one software component or language. Having the data separate from the code, and defined/managed with a language that suits data management is a feature not something to be designed out. My hunch is that people who come up with these "solutions" fail to realize this. They then condemn everyone using their layer to endless hair pulling trying to figure out "what SQL did it make from that?" and "how do I make it do this SQL?".
Is it an ORM?
From the homepage https://acadia.engineering/:
| Not an Object-Relational Mapping (ORM).
I dont see how this isn't just an ORM (like Entity Framework in dot net land).
Yeah, from the post it might even be more limited than Django (python) ever was. For example it allows the user to define its own fields, which was used over a decade ago in libraries to extend Django and provide json support long before it was officially supported.
it might semantically not be an ORM because of something at an engineering level, but it's 100% ORM like from a user point of view, so it's an ORM.
Exciting news!! Love Elm, can't wait to use it more
It looks like the HN hug of death has found a new victim
https://archive.is/fpGFV
Sorry Evan, somebody already rethought the DB https://rethinkdb.com/