Porting from Rails to a decent Ruby stack yields a lot more performance while using a lot less memory. I believe more can be gained from further optimization. Won't reach Rust levels of course so probably won't be up to Don Quixote's standards!
Last conversion of the Campfire from my token stash goes to JavaScript/Express. As with the others, I'm sure you can find more to optimize. But this gives you a sense of what order of magnitude these options exist within with agent-led development. github.com/basecamp/once-cam…
I am not sure what dhh is proposing here as he talks about exerting extreme violence? Is he calling for killing me and my family since we are Muslims living in Europe? or just expel us? Maybe force convert us to Christianity in an inquisition?
So based!
I think the Rails World keynote fueled a lot of discussion and debate in the Rails & the wider Ruby community. But I also think it's about time to have such a discussion.
I share my own experience & some of the great work the community is doing here
oldmoe.blog/2026/10/02/its-a…
I have encountered a very interesting SQLite issue (not a SQLite bug, a user error though) on a production app that I think is worth sharing.
So SQLite has this busy handler callback feature, where you register a callback to handler busy errors. The feature doc page warns:
1/n
There was no way to access this data except via this process itself and when it was killed, boof, this phantom data were all gone!
Thankfully not much was lost and most was recoverable through other means (logging, APIs)
5/n
If you are building a really high performance data ingestion pipeline, what matters most is how many pages you are touching per tx and in which cache level (L1, L2, L3) would they fit.
WAL helps, but it will largely depend on how many records are written per page in a single tx
user1: why is this slow?
rails dev investigates: oh, it’s N+1 AR queries.
user2: why is this slow?
C dev investigates: oh, it’s N+1 malloc().
the similarity is uncanny.
Spent a little time optimizing a hot route on a Ruby Roda + SQLite JSON API app
15 db queries: 1 refactored, 3 new indexes & all now use prepared statements
DB time was ~5ms per req, now ~500us per req
Most of the req time was in DB, reqs now are under 1 ms
Roda + SQLite FTW!
Great news all over, the war in Gaza seems to be over and better judgement about app server is coming into the Ruby community. Falcon improves on execution context memory overhead than any threaded/forked solution which is one of the big bottlenecks we deal with in Ruby land
Even though they try to justify their crimes, they know they are the monsters and they and their accomplices* are OK with it.
* By active support or mere silence
I believe the only chance Americans can get the Epstein truth out (and withstand the assured political avalanche) is to vote someone unrelated to both parties (and whoever is blackmailing them) to office. And that is not guaranteed, but any other way guarantees nothing happens
When building really high perf data pipelines you can hit a wall when you try to insert or update many related tables
The overheads from binding (mostly similar) data to each statement and calling them becomes a good chunk of your overhead
1/3
A more efficient way is to create a view that represents your variable set. Then create an INSTEAD OF trigger on the view to fan the data out to the target tables.
By inserting into the view, you bind the data once and visit the DB once, and all your inserts take one trip.
2/3







