benwilber0

The "runtime" word is very confusing in this case.

It's a web application server written in Rust (Axum/Tokio), that has hooks into Lua bindings (mlua) so that application behaviors can be implemented in Lua.

Looks neat. I built a programmable server for Server-Sent Events using a similar stack (Rust/mlua/axum) [1]. I think the Rust/Lua interop story is pretty good.

[1] https://github.com/benwilber/tinysse

> I am surprised more projects don’t provide a Lua scripting layer.

Completely agree. I've been adding Lua scripting support to pretty much everything I make now. Most recently my programmable SSE server [1]. It's extended the functionality far beyond anything that I would have had the time and patience to do myself. Lua is such a treat.

[1] https://github.com/benwilber/tinysse

Github was a "social network" from its very beginning. The whole premise was geared around git hosting and "social coding". I don't think it became enshittified later since that was the entire value proposition from day 1.

But why are they spending any time switching away from Redis at all unless they are a hosting provider offering Redis-as-a-service?

I wasn't aware the license had any negative affect on private internal use.

Your company invested hundreds of engineering hours switching from Redis to a clean fork of Redis?

> I probably would have gone for turning the UaF into an type confusion style attack

I'm aware that Linux is nearly 40 years old at this point, and C is even decades older. But it is mind-boggling to me that we're still talking about UAFs and jumping from dangling pointers to get privileged executions in the 21st century.

(rewrite it in Rust)

> their software also downloaded a 250MB update file every five minutes

How on earth is a screen recording app 250 megabytes

> contention slowdowns caused by having a primary key that needs a lock (incrementing key)

This kind of problem only exists in unsophisticated databases like SQLite. Postgres reserves whole ranges of IDs at once so there is never any contention for the next ID in a serial sequence.

You use a regular bigint/bigserial for internal table relations and a UUID as an application-level identifier and natural key.

> Always use a BigInt (64 bits) or UUID for primary keys.

Use bigint, never UUID. UUIDs are massive (2x a bigint) and now your DBMS has to copy that enormous value to every side of a relation.

It will bloat your table and indexes 2x for no good reason whatsoever.

Never use UUIDs as your primary keys.

Tokio + Axum + SQLx has been a total game-changer for me for web dev. It's by far the most productive I've been with any backend web stack.

Americans in the market for a "premium" shower head are clearly not looking for the cheapest thing on the market. So it's obvious that they would be willing to spend more for the added feel-good of a domestic product.

got hugged.

Maybe the next post will say "Blog is hosted on a Nintendo Wii (running Varnish)"

My initial thought is about GPG's "Web of Trust" system for trusting strangers' keys. But I don't know if that's a very good example since it always seemed somewhat esoteric and maybe not very successful in general.

I'm guessing because users will just "verify" themselves, and then the whole thing is meaningless.

The first mistake we're going to see a library developer make is:

    def execute(query: Union[str, Template]):

Maybe because they want their execute function to be backwards compatible, or just because they really do want to allow either raw strings are a template string.

the {name} parameter is in the locals() dict like it always is

Aren't there other benefits to server-side parameter binding besides just SQL-injection safety? For instance, using PG's extended protocol (binary) instead of just raw SQL strings. Caching parameterized prepared statements, etc.

Also:

    db.execute(t"QUERY WHERE name = {name}")

Is dangerously close to:

    db.execute(f"QUERY WHERE name = {name}")

A single character difference and now you've just made yourself trivially injectible.

I don't think this new format specifier is in any way applicable to SQL queries.

Don't use one of the most permissive licenses in existence and certainly not one that doesn't provide copyleft. This is all very well established at this point and yet somehow the GPL seems to have gone out of vogue.

> when we tried to use them in production at scale

Debian and Ubuntu have been using them in production and "at scale" for decades. What are the "sharp edges" that you're trying to solve?

What is an example of something that would require "distributed signing"?

Maybe I'm wrong, but aren't apt repositories just files in a web root? There are many scripts in the Debian ecosystem to generate and maintain such web directories. Maybe the actual package building would be interesting, but I don't know about just "we'll host your .deb files and keep the index updated"

I love seeing new languages targeting the Lua runtime. I've been adding Lua scripting support to pretty much everything I make now. I recently made my SSE server programmable with Lua and it's extended the functionality far beyond what I would have had the patience and time to do myself. Highly recommend Lua with mlua-rs Rust bindings.

[0] https://tinysse.com

[1] https://github.com/benwilber/tinysse

[2] https://github.com/mlua-rs/mlua

Yeah. RooCode intentionally uses one of the most permissive licenses in existence and even formally declares in the README of the project that they are not responsible for the usage or output of the software whatsoever.

And yet people will still get upset when the software isn't used like the way they want it to be used...

"just works" in the sense that this is a complete SSE client application:

    while true; do
        curl example.com/sse | handle-messages.sh
    done

Because it's just text-over-http. This isn't possible with websockets without some kind of custom client and layer 7 protocol stack.

I pretty much always prefer SSE over websockets just because of the simplicity end-to-end. It's "just HTTP", so all the HTTP-based tech and tools apply out-of-the-box without any really special configuration that is required for WS. Curl (or even netcat) "just works", no special client. I don't have to do any special CDN configuration to proxy connections or terminate SSL aside from just turning off buffering.

Websockets requires almost a completely new L7 stack and tons of special configuration to handle Upgrade, text or data frames, etc. And once you're out of "HTTP mode" you now have to implement the primitive mechanics of basically everything yourself, like auth, redirects, sessions, etc.

It's why I originally made Tiny SSE which is a purpose-built SSE server written in Rust and programmable with Lua.

https://tinysse.com

https://github.com/benwilber/tinysse

> Cannot wait to see Lua come back in full force.

I also recently released a server for Server-Sent Events [0] that is programmable with Lua. Overall it's been a great experience. The Rust mlua-rs crate [1] is trivially easy to integrate.

[0] https://tinysse.com/

[1] https://github.com/mlua-rs/mlua

I just wrote a post about this kind of stuff and why it's (almost always) nonsense. You will spend more time and effort trying to shoe-horn SQLite into a server database than you will ever get any benefits from.

https://benwilber.github.io/programming/2025/03/31/sqlite-is...

Continuing to build on my programmable server for Server-Sent Events. Built in Rust/Tokio, programmable with Lua.

https://tinysse.com/

https://github.com/benwilber/tinysse