What if SQL was like Elm? (Acadia Release!)

Show and Tell
1

Acadia is finally published!

Thank you to everyone who gave feedback! I am really happy with how it came out, and I hope people will have fun trying it out. I’m very curious to hear which languages people end up wanting to pair with it.

74 Likes
2

Congratulation on the release! Very exciting!

I’m really interested in alternative database query languages, so I’d love to get a better understanding of what Acadia query code looks like, and its capabilities. It would be fab if there was documentation of how to convert various common SQL patterns into Arcadia. e.g. different types of joins, conditional aggregates, window functions, bucketing, CTEs, correlated subqueries, etc.

11 Likes
3

This is awesome! I hope that Acadia works economically as a model for funding Elm development, and that we have a great future ahead of us!

2 Likes
4

huge. can’t wait to give it a try! congrats

2 Likes
5

How does it compare to Gel/EdgeQL?

​I think a “Why not X?”-style blog post would be really helpful for people considering adopting Acadia.

1 Like
6

We make everything by hand. Compiler, website, docs, blog, and everything in between.

Love this :heart:

5 Likes
7

Congrats on the release. +1 for Rust bindings.

4 Likes
8

Very interesting. I’m strongly considering this for one of my hobby projects.

In the Rows module, I noticed that there’s map and filter, but I feel that mapMaybe would be a really nice addition.

At the moment, to join against a variant, you have to filter first, then map and create “dummy” values.

2 Likes
9

This looks really cool. Quick note on the site: for me, middle-clicking the blog post links takes me to https://acadia.engineering/null and a 404 message.

1 Like
10

Hi Evan,

Acadia’s approach of removing error-prone choices from database programming prompted three questions about endpoint semantics. I couldn’t find these
covered in the public docs, so perhaps they are already considered:

  1. Retry-safe endpoints. If a transaction commits but the HTTP response is lost, could an endpoint atomically persist a scoped request ID and its typed
    result? An identical retry would return that result; reuse with different arguments would conflict. Retention and expiry would be explicit.

  2. Typed stale-state conflicts. Could generated clients carry a revision precondition for mutations based on previously displayed data? Transaction
    isolation does not by itself protect a user editing an old form. A typed conflict could make this boundary explicit.

  3. Transactional delivery intents. Could a transaction atomically enqueue a typed notification or webhook intent for a separate worker? This would avoid
    the commit-then-crash gap, while keeping delivery retries and recipient idempotency explicit.

These seem compatible with Acadia’s focus on a small language with strong guarantees. Do you see them belonging in Acadia, a library, or the surrounding
application layer?

11

These are interesting questions!

  1. I think this could be implemented in Acadia in a simplified form. You could store the request arguments in a table (or just a request ID + hash of args) for some fixed period of time. This might be easier once I get a function like hash : hashable -> Hash added to Acadia and Elm, but I think it’s doable without.
  2. I actually have a post written on optimistic locking that does this! You can have a type like Optimistic a on the Elm side, and have it work with tables with a version column on the Acadia side. I think that’ll cover this case.
  3. I know it’s possible to simulate a queue like this within the database, but it sounds like you are wondering about having a special purpose durable data structure for queueing. I’m open to that! I don’t think I’ll be able to implement it that soon, but I think it’d be cool.

So I think these all can be done in Acadia as is. I think the queue idea is interesting. I envision most things happening within the applications themselves for now. I am skeptical of “database packages” because I think it’s very important that people understand their database very precisely, so my plan is to see how much can be done on the Elm side. (Eventually Acadia will be able to import Elm types, and things like the Optimistic a are better implemented on the Elm side.)

I may not have understood the questions perfectly though, so please clarify if I read something wrong. It may also be worthwhile to start a new thread where it’ll be easier to get deeper into the details!

2 Likes