For inexplicable reasons I have found that some operations are only possible through the app. Ok they are not inexplicable, there is the illusion that the App is more secure and thus some high impact stuff is only possible through the app. At least in my bank.
Lol I never knew django orm is faster than SQLAlchemy. But having used both that makes sense.
> Why Rust? ... Rust handles the database plumbing. Queries are built as an IR in Python, serialized via MessagePack, sent to Rust which generates dialect-specific SQL, executes it, and streams results back. Speed is a side effect of this split, not the goal.
Nice.
So what does it take to deploy this, dependency wise?
> Lol I never knew django orm is faster than SQLAlchemy.
I don’t believe that for a second. Both are wonderful projects, but raw performance was never one of Django ORM’s selling points.
I think its real advantage is making it easy to model new projects and make efficient CRUD calls on those tables. Alchemy’s strong point is “here’s an existing database; let users who grok DB theory query it as efficiently and ergonomically as possible.”
I was surprised too when I saw the results. The benchmarks test standard ORM usage patterns, not the full power of any ORM. SQLAlchemy is more flexible, but that flexibility comes with some overhead.
That said, the ORM layer is rarely the bottleneck when working with a database. The benchmarks were more about making sure that all the Pydantic validation I added comes for free, not about winning a speed race.
Just pip install oxyde, that's it. The Rust core (oxyde-core) ships as pre-built wheels for Linux, macOS, and Windows, so no Rust toolchain needed. Python-side dependencies are just pydantic, msgpack, and typer for the CLI. Database drivers are bundled in the Rust core (uses sqlx under the hood), so you don't need to install asyncpg/aiosqlite/etc separately either.
Good question. Working with Python objects in PyO3 requires holding the GIL. With MessagePack, Python serializes to bytes, hands them off, and Rust works completely GIL-free from that point. Same on the way back. So the GIL is held only for the brief serde step, not during SQL generation or execution.
Hacks is a bit overstated, as a web dev I have lost count of how many times I have found myself trying to use broken websites and only managing to do so with manual requests from the devtools or after fixing their broken js.
Claude code with Claude 4.6 is already ahead of you, it's doing it on it's own, every now and then it updates it's "memory". Writing down stuff that happened.
That is certainly a factor, but you also have to take into account that all these tasks in the factories are now centered around the human form because humans are doing them.
Yes that's pretty much it. Some people from boston dynamics were talking on a podcast. And they were saying that they sat down with toyota and figured out they could automate all the tasks in a factory, but it would take 10000 man years or something and toyota makes new trims every six months so you need about 10000 man years every six months or so.
It's the flexibility and adaptability with minimum training that's required.
