News for hackers. Stuff that matters.

remywang

Re:Wir müssen wissen – wir werden wissen on Monday November 02, 2026 @02:00PM (#50341834)
I added the quote after seeing the parent comment-thanks for the feedback.
Re:Wir müssen wissen – wir werden wissen on Monday November 02, 2026 @10:58AM (#50338650)
I agree there is a spectrum, but we at least have to be honest with ourselves: are we really sure AI generated code is following the spec? On the other hand, with progress in proof automation, it is now feasible to formally verify AI generated code, and that allows us to specify program behavior formally, and a formal specification is again a program in itself.
Then don't grade the homework! I have in-person quizzes in my class, and the students are motivated to do the homework anyways because it prepares them for the quiz.
Re:Remove pgrust: the entry is cheating on Friday October 23, 2026 @09:25PM (#50217542)
So I spent some time poking at the released 0.4-beta code. Controversy aside, it is interesting to see an open source system that beats ClickHouse on ClickBench - 4 out of the 5 systems ahead of CH (Umbra, elosdb, Hyper, CedarDB) are all closed-source, while the only open one is pivotlake.

What makes pgrust fast? There's no one single reason, but a combination of techniques like dictionary encoding [1], zone maps [2], late materialization [3], vectorization [4], and a gazillion others. It's not unlike all the countless optimization passes in a compiler.

None of the optimizations are groundbreaking - in fact, I could find a counterpart of every optimization I checked in ClickHouse as well! So why is CH still slower?

I believe the difference is in when they decide to apply each optimization. Unlike compiler optimizations which are usually beneficial, DB optimizations are highly data-dependent, and the query planner needs to turn them on an off based on data statistics. For example, CH is more conservative in applying dictionary encoding, and it basically doesn't get used at all for ClickBench.

Turning off dictionary-related optimizations in pgrust immediately made it 5x slower (from 3.8s to 20.4s on my machine), while ClickHouse takes a total of 15.0s.

This points to one important nuance in benchmarking - when all you target is one single benchmark, you can be more aggressive during query planning, as plans that work well for one query probably also work well for others, due to characteristics shared among queries/datasets. But when you build a system that needs to support millions of users, you have to be conservative with optimizations.

[1]: https://motherduck.com/glossary/dictionary-encoding/

[2]: https://motherduck.com/glossary/zone-map/

[3]: https://arrow.apache.org/blog/2025/12/11/parquet-late-materi...

[4]: https://clickhouse.com/resources/engineering/vectorized-quer...

To turn off dictionary-related optimizations in pgrust, I used the following setting:

  SET pgrust.gravity_road_off = 'dict.entries,percode.table,percode.length,verdict.coderange,
    code.carry,code.render,code.front_part,code.front_dense,code.front_light,code.sparse,
    code.cut,code.heads,key.codeif,prefetch.fp,text.frame';
Re:Remove pgrust: the entry is cheating on Friday October 23, 2026 @11:02AM (#50210230)
Thanks for the explanation, can you release the source of 0.4-preview so that people can understand what was going on?
Hang in there! What you can build knowing how to code is drastically different from what promptards can build. Imagine trying to build a car without knowing anything about car building - you’d just get the most generic boring clunker anyone can design.
Every verification needs a spec, and in this case the spec is the Postgres implementation. I think we can and should do a lot better than taking 2.6 million lines of C code as the spec.

In general, the spec must be human readable, and I believe to achieve that we must do away with SQL. Putting aside the thousands of pages of SQL standard, even the core subset has a gnarly semantics due to issues like nulls.

A simpler semantics is one of the main motivations behind Prela [1], and despite its simplicity, we now know it’s powerful enough to express thousands of queries in the wild [2], as well as run doom [3].

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

[2]: https://github.com/remysucre/prela/tree/sqlstorm

[3]: https://github.com/remysucre/prela/tree/doom/

> I wrote a compiler that can translate both Rust and C code into Lean

How do you verify this compiler is correct? To do that, I think you at least need a formal semantics for both C and Rust in Lean, both sound like Herculean efforts

Re:Railway Security Disclosure on Wednesday October 21, 2026 @09:00PM (#50189788)
Services you were responsible for
Re:11 of 23 Core Open Source Projects Run on 1 or 2 People on Friday October 09, 2026 @09:34PM (#50028632)
> Eight projects, including … SQLite … show no grant or sponsorship in any public funding source the analysis checked

SQLite has a list of sponsors right on the homepage https://www.sqlite.org/

Re:Why the AI future will be awesome on Thursday October 08, 2026 @11:06AM (#50006723)
So much nonsense on HN front page these days, the algorithm desperately needs to be redone
Re:Living off-grid: Hundred Rabbits on Thursday October 08, 2026 @03:12AM (#50002702)
I greatly enjoyed reading their sail log crossing the Pacific Ocean, very poignant and down to earth: https://100r.co/site/busy_doing_nothing.html
Re:Subquadratic 3SUM and Subcubic APSP on Tuesday October 06, 2026 @09:04PM (#49986556)
Yes that’s the idea, these conjectures basically say “there’s no better algorithm than the naive/brute force one”. It’s like if P!=NP, then there’s no (asymptotically) better algorithm for SAT than naive backtracking search.
Re:Subquadratic 3SUM and Subcubic APSP on Tuesday October 06, 2026 @01:30PM (#49981580)
3SUM is (was?) one of the key conjectures in fine-grained complexity, mostly used to derive lower bounds for other problems. As such, most did not think a subquadratic algorithm was possible. Similar for APSP
Re:pldb: programming languages papers on Wednesday September 30, 2026 @09:18PM (#49916527)
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.
Re:Advice to a Beginning Graduate Student (2001) on Friday September 25, 2026 @08:07PM (#49851758)
lol along those lines yes
Re:Advice to a Beginning Graduate Student (2001) on Friday September 25, 2026 @04:53PM (#49849815)
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.
Re:Opus 5.5 is good at explainer videos on Friday September 25, 2026 @01:49PM (#49847759)
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

Re:Anecdotally, Programmers Dislike "Reduce" on Wednesday September 16, 2026 @08:59PM (#49735151)
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

Older »