rfcs
logica
rfcs | logica | |
---|---|---|
5 | 19 | |
34 | 1,682 | |
- | - | |
4.6 | 9.1 | |
4 days ago | 17 days ago | |
Python | Jupyter Notebook | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
rfcs
-
Show HN: Starter.place – Gumroad for Starter Repos
Search it is! I could implement search that searches for exact tokens in the tools the author connected and the README, but I want to wait for anything more until EdgeDB releases its full-text search solution https://github.com/edgedb/rfcs/blob/master/text/1015-full-te...
I actually had a feature in mind where people could vote on starters they want and others could build them out and list them for free or a price. Do you think that would fit your needs and is there anything in particular you'd want to see in a feature like that?
-
Show HN: PRQL 0.2 – Releasing a better SQL
Replied on Twitter!
> I see EdgeDB as primarily focused on transactional queries, whereas PRQL is very focused on analytical queries.
That's true to an extent currently, but we actually envisioned EdgeQL to be a capable analytical query language too. We'll release EdgeDB 2.0 in a couple of weeks and it will feature a powerful GROUP BY statement (read more about it here [1]) and in 3.0 we might ship window functions (or some equivalent).
With all that said PRQL looks cool!
[1] https://github.com/edgedb/rfcs/blob/master/text/1009-group.r...
-
EdgeDB 1.0
>> We shall do better than SQL
> The EdgeQL language looks cool, and I'm sure querying via a graph structure makes certain problems easier in some use cases. However as much as people have complained about SQL, it's just so ubiquitous there needs to be a very good reason to switch away from it. Not having to write joins isn't really a good enough reason, in my opinion.
Oh, it goes much deeper than not writing joins. There's no single ORM out there that can implement a TypeScript query builder like ours, see the example in [1]. This is only possible because of EdgeQL composability, but that composability required us to rethink the entire relational foundation.
> > The true source of truth
> I'm not sure why this means EdgeDB is better. <..>
This section implies that EdgeDB's schema allows to specify a lot of meta / dynamically computed information in it. And soon your access control policies. Take a look at the work-in-progress RFC [2] [3] to see how this is more powerful, then say, Postgres' row level security.
> > Not just a database server
> It sounds like they have a solid client, which is awesome.
Also lightweight connections to the DB so that you can have thousands of concurrent ones without load balancers, built-in schema migrations engine, and many other things. In fact we have so much that it's challenging what to even highlight in a blog post like the 1.0 announcement.
> Cloud-ready database APIs
> This used to be true, but is definitely no longer true. Cloud-native databases are everywhere and incredibly common. See any major cloud, https://www.cockroachlabs.com/, or any of the tons of other database solutions.
Not to pick on CockroachDB (they have an amazing product and company, we love them), but you should benchmark local install of Postgres and Cockroach to see yourself that scalability still has a significant cost in performance.
[1] https://www.edgedb.com/blog/edgedb-1-0#not-just-a-database-s...
[2] https://github.com/edgedb/rfcs/pull/49
[3] https://github.com/edgedb/rfcs/pull/50/files
-
Show HN: PRQL – A Proposal for a Better SQL
EdgeQL is getting support for generic partitioning/aggregating `GROUP` very soon [1], so we are giving some love to the analytical side of things too :-)
We definitely need more collective effort put into "Better SQL", so PRQL is a welcome sight!
[1] https://github.com/edgedb/rfcs/blob/21e581a188715c6ff82944b6...
logica
-
Prolog language for PostgreSQL proof of concept
If you're interested in this I would also recommend you check out Logica[0], which is a datalog-like language that is explicitly made to compile to SQL queries.
0: https://logica.dev/
- Logica
- New welcome page for Logica language
-
Introduction to Datalog
> I guess the intention is to be better than SQL but then I was left with "under which circumstances?"
Excellent question.
Two of the most common use cases for databases are "transactional processing" (manipulating small numbers of rows in real time) and "analytical processing" (querying enormous numbers of rows, typically in a read-only fashion).
SQL is generally fine for transactional workloads.
But analytical queries sometimes involve multi-page queries, with lots of JOINs and CTEs. And these queries are often automatically generated.
And once you start writing actual multi-page "programs" in SQL, you may decide that it's a fairly clunky and miserable programming language. What Datalog typically buys you is a way to cleanly decompose large queries into "subroutines." And it offers a simpler syntax for many kinds of complex JOINs.
Unfortunately, there isn't really a standard dialect of Datalog, or even a particular dialect with mainstream traction. So choosing Datalog is a bit of a tradeoff: does it buy you enough, for your use case, that it's worth being a bit outside the mainstream? Maybe! But I'd love to see something like Logica gain more traction: https://logica.dev/
-
Mangle, a programming language for deductive database programming
Interesting; a Google engineer previously published a Datalog variant for BigQuery: https://logica.dev/
This new language seems similar to differential-Datalog (which is sadly in maintenance mode): https://news.ycombinator.com/item?id=33521561
- Show HN: PRQL 0.2 – Releasing a better SQL
-
Show HN: PRQL – A Proposal for a Better SQL
Looks pretty cool. I'd be interested if the README had a comparison with Google's Logica (https://github.com/EvgSkv/logica)
-
PathQuery, Google's Graph Query Language
Oh wow that is neat!
And yes, this kind of thing is why datalog is a lot more amenable to fast query plans & runtimes than prolog. This part is especially cool: https://github.com/EvgSkv/logica/blob/main/compiler/dialects...
-
Thought about Logica: Google new programming language that compiles to SQL ?
Google new programming Language that compiles to SQL (Support BigQuery and Postgres) feels very exciting. Blog: https://opensource.googleblog.com/2021/04/logica-organizing-your-data-queries.html Github: https://github.com/EvgSkv/logica
-
Google Logica Aims To Make SQL Queries More Reusable and Readable
Going to be? It already is. In fact, one thing the article misses is right there at the bottom of the project page:
What are some alternatives?
prql - PRQL is a modern language for transforming data — a simple, powerful, pipelined SQL replacement
scryer-prolog - A modern Prolog implementation written mostly in Rust.
partiql-lang-kotlin - PartiQL libraries and tools in Kotlin.
ungoogled-chromium-archlinux - Arch Linux packaging for ungoogled-chromium
malloy - Malloy is an experimental language for describing data relationships and transformations.
edgedb - A graph-relational database with declarative schema, built-in migration system, and a next-generation query language
imdbench - IMDBench — Realistic ORM benchmarking
dbt-core - dbt enables data analysts and engineers to transform their data using the same practices that software engineers use to build applications.
edgedb-java
differential-datalog - DDlog is a programming language for incremental computation. It is well suited for writing programs that continuously update their output in response to input changes. A DDlog programmer does not write incremental algorithms; instead they specify the desired input-output mapping in a declarative manner.