Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • 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.

    by raumgeist
  • > …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.

    by schaefer
  • 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.
    by huahaiy
  • So this is capable of turning a one-liner of SQL into six lines of barely readable code?
    by pelagicAustral
  • SQL is a horrible language. I’d gladly program in something composable like Elm.
    by janderland
  • 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.
    by fwlr
  • Some interesting features here:

    - sum types/ADTs have been long missing from database data modeling and this is welcome change. It's not entirely clear to me how the migration strategy here will work with things like removing a variant, etc.

    - first class enforced RLS - this seems like a fantastic way to ensure safety/security guarantees. Secure by construction is always preferable to bolt-on security controls.

    - composability with a strong module system. I think this will work well in ensuring large schemas can evolve over time. I wonder if there will be package manager in the future.

    by gampleman
  • 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.

    by mjaniczek
  • New functional query language for PostgreSQL and SQLite by Evan Czaplicki the author of Elm
    by honungsburk
  • 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?

    by bbkane
  • 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?

    by let_rec
  • 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.

    by jeremyjh
  • 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.

    by gbjcantab
  • 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.
    by happyraul
  • 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.

    by dwohnitmok
  • 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
    by exidex
  • By now I stopped counting the attempts to replace SQL.

    There is a lot of valid critic for SQL and I would be very happy if some things would have been designed different.

    OTOH the architecture and mathematics behind relational databases are simple, composable and stood the test of time more than most other designs, methodologies or approaches to software development.

    Though SQL can be improved, even with my average SQL skills I never had trouble getting information out of a database and fancy stuff like window functions make to my understanding even standard SQL Turing complete.

    SQL has the native database support, for most companies the data and the database will outlive any specific application or even the whole ecosystem of a programming language/platform (Visual Basic, Visual FoxPro, Python 2, ...)

    Further, we have fantastic books, knowledge, ORMs, query builders and a gigantic ecosystem in tools for SQL and SQL databases.

    Acadia might be brilliant from a technological point of view, but it does not matter, because it does not look like a big enough improvement compared to SQL that it seems worth to invest in it. I will rather improve my knowledge of standard SQL or my knowledge for a specific relational database.

    Finally Acadia does not really seem to raise the bar compared to other ORMs/Query builder. I get that from a FP point of view map/filter are nicer than a SELECT ... WHERE, but at some point in the projects I participated one would end up interacting directly with the database anyway, and at that moment I am back at SQL, so what did I gain?

    by CopyOnWrite
  • SQL is based on the relational model but doesn't really conform to the mathematics e.g. doesn't exhibit set semantics.
    by ModernMech
  • SQL has one flaw: The verb should come last. So, "FROM users WHERE id = 1 DELETE" or "FROM users WHERE email = 'foo@example.com' SELECT id". That'd cut back on some accidental "oops I dropped the whole table" because I submitted a delete query before writing the where clause.

    Other than that, it's perfect, no notes.

    by ninkendo
  • 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.

    by mike_hearn
  • > 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?

    In Prolog you'd just handle those as metapredicates. There are a million different ways to skin the cat there. For example on partitioning schemes:

      :- vertical_partition(profile/4, [
      core(1, 2),       % UserID, Username -> stored in primary memory
      metadata(1, 3, 4) % UserID, Bio, Preferences -> stored in cold storage
  ]).
    by ux266478
  • 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.

    by bazoom42
  • 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.
    by Smalltalker-80
  • 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.
    by adzm
  • 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.
    by alpinisme
  • 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.

    1: https://github.com/Araq/ormin

    by elcritch
  • > 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:

        DATABASES = {
        "default": {
            "ENGINE": "django.db.backends.postgresql",
            "NAME": "mydatabase",
            "USER": "myuser",
            "PASSWORD": "mypassword",
            "HOST": "localhost",
            "PORT": "5432",
            "OPTIONS": {
                "options": "-c search_path=myapp,public",
            },
        }
    }
    Or you have to do it from the postgresql side:

        ALTER ROLE myuser
    IN DATABASE mydatabase
    SET search_path = myapp, public;
    It's not ergonomic at all.
    by znpy