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.
> 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.
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.
> 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.
> 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.
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.
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.
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.
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.
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.