Didn't the committee agree that ORMs were a mistale and a thing of the past?
Show HN: Oxyde – Pydantic-native async ORM with a Rust core
11–20 of 91 posts
Re: Show HN: Oxyde – Pydantic-native async ORM with a Rust core
#12> But infrastructure stuff like SQL generation, connection pooling, and row serialization is where a systems language makes sense. not really, what makes sense is being JIT-able and friendly to PyPy. > Type safety was a big motivation. > https://oxyde.fatalyst.dev/latest/guide/expressions/#basic-u... > F("views") + 1 If your typed query sub-language can't avoid stringly references to the field names already defined b…
The Rust core is not just about speed. It bundles native database drivers (sqlx), connection pooling, streaming serialization. It's more about the full IO stack than just making Python faster.
On F("views"), fair point. It's a conscious trade-off for now. The .pyi stubs cover filter(), create(), and other query methods, but F() is still stringly-typed. Room for improvement there.
Re: Show HN: Oxyde – Pydantic-native async ORM with a Rust core
#13Lowkey hope this replaces Django ORM
Re: Show HN: Oxyde – Pydantic-native async ORM with a Rust core
#14Didn't the committee agree that ORMs were a mistale and a thing of the past?
Must have missed that meeting. ORMs are not for everything, but for CRUD-heavy apps with validation they save a lot of boilerplate. And there's always execute_raw() for when you need to go off-script.
Re: Show HN: Oxyde – Pydantic-native async ORM with a Rust core
#15Lowkey hope this replaces Django ORM
Thanks! Not really trying to replace Django ORM though, it's great at what it does. Just trying to build the ORM I'd personally want to use in 2026.
Re: Show HN: Oxyde – Pydantic-native async ORM with a Rust core
#16Didn't the committee agree that ORMs were a mistale and a thing of the past?
Must have missed that meeting. ORMs are not for everything, but for CRUD-heavy apps with validation they save a lot of boilerplate. And there's always execute_raw() for when you need to go off-script.
[dead]
Re: Show HN: Oxyde – Pydantic-native async ORM with a Rust core
#17We need more creative names for rust packages because this is going to cause confusion
There's already Oxide computers https://oxide.computer/ and Oxc the JS linter/formatter https://oxc.rs/.
Re: Show HN: Oxyde – Pydantic-native async ORM with a Rust core
#18Didn't the committee agree that ORMs were a mistale and a thing of the past?
Micro-orms (mapping to parameters and from columns) are generally fine last i read. It is the general aversion to writing a SELECT that is suspect.
Re: Show HN: Oxyde – Pydantic-native async ORM with a Rust core
#19We need more creative names for rust packages because this is going to cause confusion There's already Oxide computers https://oxide.computer/ and Oxc the JS linter/formatter https://oxc.rs/ .
Yeah, we're running out of ways to spell oxide (^_^)
Re: Show HN: Oxyde – Pydantic-native async ORM with a Rust core
#20> But infrastructure stuff like SQL generation, connection pooling, and row serialization is where a systems language makes sense. not really, what makes sense is being JIT-able and friendly to PyPy. > Type safety was a big motivation. > https://oxyde.fatalyst.dev/latest/guide/expressions/#basic-u... > F("views") + 1 If your typed query sub-language can't avoid stringly references to the field names already defined b…
The Rust core is not just about speed. It bundles native database drivers (sqlx), connection pooling, streaming serialization. It's more about the full IO stack than just making Python faster. On F("views"), fair point. It's a conscious trade-off for now. The .pyi stubs cover filter(), create(), and other query methods, but F() is still stringly-typed. Room for improvement there.
> It's more about the full IO stack than just making Python faster.
Does it mean that your db adapter isn't necessarily DBAPI (PEP-249) compliant? That is, it could be that DBAPI exception hierarchy isn't respected, so that middlewares that expect to work across the stack and catch all DB-related issues, may not work if the underlying DB access stack is using your drivers?
> but F() is still stringly-typed. Room for improvement there.
Yeah, I'm pretty sure F() isn't needed. You can look at how sqlalchemy implements combinator-style API around field attributes:
import sqlalchemy as sa
from sqlalchemy.orm import DeclarativeBase
class Base(sa.orm.DeclarativeBase):
pass
class Stats(Base):
__tablename__ = "stats"
id = sa.Column(sa.Integer, primary_key=True)
views = sa.Column(sa.Integer, nullable=False)
print(Stats.views + 1)