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.

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.