If bun can rewrite its entire code from zig to Rust, why can’t Django introduce truly Async ORM?
Because there are many of us that simply aren’t interested in async Django.
Also, doing this while keeping 100% compatibility with existing code (Django and third-party) makes this difficult-if-not-impossible.
See Loopwerk: Async Django: a solution in search of a problem? for another pespective on this issue.
To add what @KenWhitesell I think that, assuming free threading efforts in Python deliver in term of performance in the next versions, adapting the core to take advantage of it is going to be way less invasive for the code base and for our users.
Compared to switching to async they should be able to continue to use the well established sync interfaces, which are already thread safe, and reap the benefits for free as long as they use thread based worker pools over process (e.g. pre-fork) based ones.
A rewrite maintains feature parity, and has an existing bar to hit (which can be measured using a test suite). Adding native async is new functionality - without the same test harness or known bar to hit.
“Here’s a vibe-coded async ORM” would be a bit of a slap in the face to people who have come to trust and rely on Django’s reliability, stability and quality.