Comment by AaronFriel | Hacker News Reader

Comment by AaronFriel | Hacker News Reader

Django is, of course, an open source project and the core team and contributors are largely free to work on whatever they prefer.

However, as a user of Django I sincerely wish they would focus more on stability:

Changing jsonb deserialization in a patch release, 3.1.1: https://code.djangoproject.com/ticket/31956#comment:16

Queryset .get() can cause OOM, ticket has gone back and forth, problem existed as recently as Django 2.X: https://code.djangoproject.com/ticket/6785

Django's cascade options differ from the database's, are manually implemented: https://code.djangoproject.com/ticket/21961

Can't update keys via ORM, related to the above: https://code.djangoproject.com/ticket/21265

Inconsistent behavior around constraints checking in unit tests, can lead to inexplicable behavior and difficulty testing when a constraint is violated: https://code.djangoproject.com/ticket/11665

In general, the ORM functionality and the inconsistency, bugs being introduced in patch releases has me looking elsewhere for all new development and recommending to other engineers the same.

We have a running joke in our engineering team that every bug we hit in Django will have an open or "closed wontfix" issue 5-10 years old.

I love Django, but version upgrades are a gigantic hassle.

What would you suggest as an alternative for a new project?

Django is still my go-to. Specifically [Django-REST-Framework](https://www.django-rest-framework.org/) with a front-end written with [react-static](https://github.com/react-static/react-static).

Django's ORM is so nice and the ecosystem around it rocks.

Its biggest downside is painful upgrades. They don't really follow [semantic versioning](https://semver.org/)

To me however the ORM is one of the most annoying things. Not a fan of ORMs in general, but Django's implementation promotes a usage pattern where django-models are passed around everywhere, leading to hard to untangle dependencies between services once they do literally anything with the objects.

I'm relatively new to Django (longtime Flask user), and what struck me about the Django ORM so far is that it seems much easier to write extremely low performance queries. I didn't really feel this way when using SQLAlchemy or peewee, but perhaps that's just my inexperience.

I really enjoy the Django ORM, and it is perhaps the main reason I still use it today. Right mix of simplicity and power.

we are using FastAPI + SQLAlchemy here.

Are you married to Python? Ruby on Rails is mature, with a large set of useful libraries.

We're not married, but we're "living in sin"... Once python shows you that blocks are always encoded with indentation for the human readers, then braces or beg/end are just static/visual interference on top of your code that makes it harder to read. Going from python back to braces or beg/end is like going from DVD back to VHS. You didn't notice how bad the static on VHS was until DVD showed you a better way. :-D

<touches off small fire>

I guess I've tended to be more focused on how much I can produce and the quality of the ecosystem vs that level of syntax. My limited experience is that other frameworks, languages and ecosystems allow for more productivity overall. The few places I know using Django are not as productive as the orgs I know using either Laravel or Rails. There may be some 'chicken/egg' stuff going on, but... if lack-of-braces means that much to you, that you'll cut off using other tech stacks altogether, so be it.

Heheheh. I'm a code craftsman and certain tools I enjoy more than others. It's OK to love the heft and feel of a model-77 wormdrive skilsaw and also to enjoy the cleanliness and readability of python code. Right tool for the job, but ceteris paribus, I prefer python. The tool feels good in your hands. I regularly code in C++, javascript, Rust, and python so I haven't joined a cult, but yes, I do enjoy python.

funny, I feel the same way about Ruby going to Python - i don't like list comprehensions, for example - feels so crusty and limited compared to yielding blocks in ruby

Is there a framework that does them better? The 1.6 transition was the only one that took more than a day for me.

I'll second this - I maintain a few different Django backends and it's been smooth sailing upgrading most of them.

Yeah. Tons of other frameworks do it better. React for instance. Any framework that actually follows [semver](https://semver.org/) and really cares deeply about backwards compatibility. I've hit backwards incompatibility on almost every upgrade. Not just major 2->3, but each minor release.

I still love love love Django, but I do wish upgrades were easier.

What kind of things have you hit? I think the last time I had an upgrade take more than a few minutes was around the 1.6-era.

(As a reminder that projects vary, I've had more times where I've had to spend time fixing React projects — usually not core but related plugins – so I think there's a heavy element of what you do and how the team works coloring impressions)

Maybe try the new django-upgrade package. https://github.com/adamchainz/django-upgrade

It claims you can either just run it or hook it into your CI. It will automatically take care of some of the upgrade chores for you.

I really wish they'd prioritize multi-column primary keys. I don't have a ticket handy, but it's been out there for many, many years as well. I feel like it would be huge for projects built on legacy database, where you have to rely on existing schema.

Even if it isn’t a legacy project, sometimes you just so happen to have a natural composite key on a table and don’t want to assign a separate single column primary key just to satisfy your ORM.

Reply on news.ycombinator.com