remywang

What does this add over https://dblp.org/?

By the same reasoning, why should I care about the output of someone else’s clanker if I can just get it from my own clanker?

But to answer your question, I do still care about software being maintained by someone who can make design decisions instead of just yielding control to bots who tend to produce mediocre designs.

One cool factoid about PEGs is that it is an open problem if they can parse all context free languages.

lol along those lines yes

This can be good advice if worded a different way: only go to grad school if you really love doing research. If you love research, then the right graduate program is the best place for that. Getting a PhD was the hardest thing I’ve ever done but I don’t regret a single day of it.

Explainer videos should focus on explaining, but these videos are nearly content-free.

Kurzgesagt makes some of the best explainer videos, and they spend most of their time writing the script, not making the animation: https://youtu.be/uFk0mgljtns?si=NCMxIYGUYY-BbQgB&t=75

I’m so confused, how are you supposed to perform aggregation without reduce? This is like saying “I like plus and times, but I don’t like divide because it’s hard.” I mean sure, but you need it??

Very practical approach to “query optimizer as a service”, but I find it cursed that we have decided SQL is the IR for databases

What website are you talking about? This has nothing to do with AI.

The root of all these is the culture in mathematics (and science in general) to only reward those who “get there first”. This creates a perverse incentive to compete. When no one can out compete a tireless swarm of AI, no one gets rewarded any more.

But nothing’s stopping anyone to still work out an alternative proof, or a more elegant proof, or just trying to prove for the sake of understanding, just like doing homework without looking at the solution. It’s just that you can’t get paid doing that anymore.

People saying “he should have opted out” are missing the point. OpenAI can and should check their training data for leakage in the face of big breakthroughs like these. It’s the burden of the author to appropriately cite their sources.

It’s like a scientist refusing to give another one credit and say “sucks to be you, you shouldn’t have shared your idea with me”.

Light is making a flip phone [1], and it's somewhat hackable now that they release an SDK [2]

[1]: https://www.thelightphone.com/shop/products/light-flip

[2]: https://developers.thelightphone.com

There has been no movement on this since 2023, and Migicovsky is now busy with reviving pebble

It's rather convenient for OpenAI that user logs are de-identified before being fed into training, so they can say "there's no way for us to check if we plagiarized our user's work, because user data is private".

It's also difficult to imagine any competent AI researcher would overlook the possibility of training data leaking into the test, especially given that they know the users have been using their model to work on the same problem, and that they jumped on the problem after hearing rumors of the breakthrough.

Feline cancer cure slowed by shortage of treats, says my cat

Thanks! Alloy is also based on TAR, they just call it the more common name of relation algebra (not relational).

The remaining 1% is usually uncomfortable if not down right painful.

But yes, I agree a query optimizer is valuable. Luckily there’s nothing stopping us from implementing one, as Prela is algebraic and all optimization techniques for SQL carry over.

They are exactly the same!

Yes this is correct, thank you.

Ah, that's not what I meant to say. You're talking about bag vs set semantics. Prela implements bag semantics just like SQL.

That sentence should say "a binary relation can map an input to multiple different outputs", and that's not a bad thing. It's exactly how binary relations generalize functions, and we want that because that lets us compose binary relations like how we compose functions!

Author here, I will be at VLDB in Boston this coming week and will be very happy to chat about Prela.

Unrelated, we also have a tutorial on instance-optimal join algorithms: https://www.vldb.org/2026/program.html#tut-2

With some syntax sugar it looks almost exactly like SQL [1]. Here I’m showing the unsweetened edition for didactic purposes.

[1]: https://remy.wang/blog/prela.html

Here are some SQL queries from standard benchmarks rewritten in Prela: https://github.com/remysucre/prela/tree/cidr#queries

This is in rust and we’re still tweaking the language, so the syntax is slightly different from the post.

Compositionality is hard to show with a small example because it really only comes through at scale.

If anyone can point me to a huge SQL query, I’ll take it up as a challenge to rewrite in Prela!

Prela’s semantics is based on an algebra of binary relations (unfortunately called relation algebra [1]), not the standard relational algebra.

[1]: https://arxiv.org/abs/2607.26356

1. Yes

2. No. Prela’s speedup is largely due to indexing. We tried to port the same indexing tricks back to duckdb but it wouldn’t let us. See the paper [1] for details

3. Prela focuses on analytical queries at least for now

[1]: https://arxiv.org/abs/2607.26356

The point of Prela is exactly to remove that step of indirection, it gives you ORM ergonomics but compiles directly to operations on the physical columns, skipping SQL. At least for me I find it easier to think in Prela than to think in SQL, especially for complex queries, and I believe you’ll feel the same with some practice.

Yes basically. But DuckDB actually does not build an index on the keyword text. It only builds primary key indices automatically on data load. The standard benchmark schema specifies fk indices but not one for the keyword text.

Thank you! Prela’s `.and` operator is exactly the fork in fork algebra. I also suspect you will get `.select` and `.and` if you lift >>> and &&& to the category of Rel.

> I wonder where the limitations of this approach are seen?

Compile time. Rustc takes forever to compile, much longer than the time it takes to run the query. There’s plan to build a JIT for Prela, which would also improve the interop.

Most of the language design is orthogonal to the embedded implementation though, and Prela could very well be implemented in a vectorized engine.

If you like DuckDB, please consider funding DB research [1]!

[1]: https://news.ycombinator.com/item?id=49336147

Remy Wang, Assistant Professor @ UCLA

https://remy.wang

Working on:

- Query languages (Prela [1] and Datalog)

- Join algorithms (WCOJ, instance-optimal joins [2], join ordering)

[1]: https://prela-lang.org

[2]: https://arxiv.org/abs/2601.00098