> I don't think I would use it enough to justify the investment
This is not a rational purchase - most of the rule breaking done with the zero is for fun or convenience, rather than being truly illegal.
It used to be more fun before the hotels started handing out NFC unlocks with your phone.
Still, being able to send each other a key for a hotel room on Signal is a nice trick if you are traveling with a sufficiently tech savvy group of people.
The rule partial order problem seems to be very similar to how Rule engines are optimized for ACL rule application.
> Once per candidate, we precompute a bitmask, an integer whose bits flag which rules that candidate is eligible for. For a pair, the bitwise AND of their two masks is exactly the set of rules both are eligible for, and we check only those.
Once I see a bit-mask loop, the next item I pick up is a Karnaugh Map[1] as a way of looking at the rules.
If one side is generally immutable to automatically reorder the generators of the bits (i.e can I turn a 192 bit expression into a 64 bit followed by a 128 bit - if so which bits are important).
The C++ template hacks over this looks a bit like a fastdiv from Lemire.
The specific one where I spent 2+ months optimizing this was the UserAgent matcher with regexes - an extension replacement for the get_browser() in PHP where the goal was to split up the regexes and build a KV Map for it, so that you can run 40+ small regexes instead of looping through 400.
The name makes me think it is a molten salt reactor, but it uses liquid sodium. Still aptly named.
I was hoping the Thorium molten salt ones with atmospheric pressure vessels would pick up pace thanks to this boom in power demand or Helion would arrive on the scene right on time for this.
That section is the most relevant whenever compression in a DB is discussed.
The purpose of a database is to find, aggregate or update data - storage is where the trade-off gets expressed. There are no silver bullets here.
Any method of compression which speeds up either filter rejection or scan rate is better than something that only trades off IO for CPU usage.
For example, dictionary encoding can be slower to read (because you decompress the whole dictionary and not just the skip read after filter), but not if you can squeeze out an IN clause by turning string comparisons into O(1) dictionary followed by a simple integer filter. Remember, this can be arbitrarily complex (Druid is a great example of this) and then the bitmaps can be used because the dictionary index will be a dense 0-N.
Even better if that can feed a deterministic operation like UPPER() so that you do it over the dictionary hits once, instead of each row. You can even use it over the same hash slot, instead of another dictionary collision check or hash computation.
If anyone is looking at JSONB compression, go take a long look at the Variant encoding proposals from Databricks/Snowflake for Iceberg[1].
Turning a single column "payload" JSONB field into chunks which are columnarized and strictly typed allows you to do all the tricks mentioned here, but on loosely typed data but chunk by chunk.
> So in terms of allocating space, it's more like a delete plus an insert.
Unless you're using zHeap, you have a narrow Heap-only-Tuples scenario where the indexes stay the same. TOAST kinda helps there, if the update is off the tuple area itself. The original zHeap docs have a lot of detail about why an UNDO log can help with long running transactions from the past etc.
That is a postgresql specific thing though. Mysql indexes were created with the idea of different storage engines in mind, so Mysql doesn't suffer from the index update ovehead on update/delete the same way.
Uber had a long blog post about switching to Mysql from Postgres for wide tables with hundreds of indexes. The HN entry is still there[1], but I can't read the original post now.
As a side note, I've used postgres partitions to the same effect to drop old data periodically - detach and then drop the partition instead of a direct DELETE (similar tricks in HBase existed).
The non-professional side of Organic Chemistry is one place where I think AI would really shine.
Feels complex like solving a Rubik's cube to write down synthesis steps but it is all a sequence of memorized tricks. Do Cannizaro if you want this, Bergmann to do that.
But the synthesis plan is only 10% of the actual work.
The gap between writing down the synthesis step and actually doing it is also extremely large.
Even if you get the right molecule, it might be the wrong way around or just clump up into a useless mess.
The Ritonavir episode of Veritasium is a great example of how all chemistry on paper is a mere shadow of what actually happens in real life.
The weird thing is that this is probably a performance optimization for quick responses when a user asks a question.
My agent harness spins up a VM too, but it spins up on demand, cools down in 10 minutes and warms up when I focus back on the app.
The files it works on actually lives in a mount.
People take more time to type a prompt than the VM takes to spin up on a fast machine and on a slow machine, the cooldown naturally frees RAM back to the machine.
> Again, it wasn’t perfect. As an expert, I was able to spot some errors and omissions (some as a result of the design I had asked for) that I had the AI correct
That's the bit that stuck out to me - that's longer than I would expect to work on a problem in a day or even expect to go back & fix the output of something that has a core reward loop of hours.
My customers are currently clamoring to push down my agent response times from 85 seconds down to below the 20s mark.
At the same time, it is very dissonant to see the industry heading towards hour+ long workflows with an agent.
> an example of a case where you'd use SQLite instead of jq or grep through Markdown?
Usually we end up writing a script to incrementally refresh a data-set I'm analyzing (or have someone send me a copy after they pull it).
I've been using sqlite for anything which needs an UPDATE - modifying a row deep inside the data-set with jsonl is a pain.
My github is full of java programs which update sqlite3 files with threadpools and a single big lock around the UPDATE (& then I write or have an agent write code to analyze it).
DuckDB is slowly replacing it in the context of python, simply because of the ease of pushing a UDF into the SQL.
Also because I really like expressing things as LEAD/LAG with a UDF on top.
> Well, there is also a big difference that it will not learn over time.
My work is in tick-tock loop of learning - learn without modifying weights, demonstrate learnings to human, but then lock it back in (accumulate and spread).
This looks less like training and more like mentoring.
Getting a human to mentor an agent is a hard UX task, but the learning loop is not a technological problem anymore.
We can only get a tick once a week, no matter how many tocks we can do an hour.
If you manage 500+ people organization, most of the headaches with agents already exists with you - you set directions, ask people to go run fast in those directions, check in frequently and course correct on results without actually understanding those people do.
Those aren't the deal breakers.
They entirely rely on the competence of the folks they hired and cross-match enforcers with the drivers they have - they deal with fallible people on both sides of that.
The fundamental difference is that the humans are good consequence predictors, have built up reputations they are not willing to trash, can say no to things and in general don't want to go jail.
AI tools look like that, but don't have any of the useful conflict which came for free with employing humans.
It also doesn't have any useless conflict, but not all conflict between what I say and what someone is willing to do is bad conflict.
In my small circle of car friends, the new Ferrari is being called the "Magic mouse" of ferraris and posting memes of the car upside down with the cable plugged in at the bottom.
I was hoping for an SF90 meets Nevera when they were talking about it originally :(
But that is entirely unoriginal and derivative, compared to a designer wanting to make a mark.
The AI psychosis is not the anti-opinion to the use of AI.
I use AI coding tools every day, but AI tools have no concept of the future.
The selfish thinking that an engineer has when they think "If this breaks in prod, I won't be able to fix it. And they'll page me at 3AM" we've relied on to build stable systems.
The general laziness of looking for a perfect library on CPAN so that I don't have to do this work (often taking longer to not find a library than writing it by hand).
Have written thousands of lines of code with AI tool which ended up in prod and mostly it feels natural, because since 2017 I've been telling people to write code instead of typing it all on my own & setting up pitfalls to catch bad code in testing.
But one thing it doesn't do is "write less code"[1].
https://aidnn.ai