The small changes in 2.7 were understandable, but quiet a few gems that I used broke in 2.4, and in 2.5. It was a pain to fix, some were never updated.
Much how people complain that changing strings in Python 2->3 hurt adoption; we have had breaking changes that can break gems almost every release.
Ruby is a great language, but Python is so much less stressful, easier to find working libraries, and easier to find jobs. The last reason is likely because of the first two.
It is fine to add things, but when you keep changing the language and breaking things; people hesitate to write software in it. There is a reason the Linux kernel has a rule about (almost) never breaking user-space.
In the mid 2010s the python web application space felt very stagnant to me, many semi abandoned projects, lots of people leaving for other technologies. But there has been quite some reversal on that since.
I can't grok it completely. All the books that I read on it skipped the architecture part.
Maybe there is a good guide to Django architecture - the big picture?
PS I am rather experienced in Python (Numpy, Pandas, Plotly, Flask, SQLAlchemy, FastAPI, BeautifulSoup are my bread and butter)
The Django file structure, for example, is not exactly optional in Django. Realize FastAPI follows in the footsteps of Flask. Neither FastAPI or Flask are frameworks. As a FastAPI user myself, I do think it’s closer to a happy medium, but it’s nothing remotely comparable to Django.
When using Django, the best advice I have is to dive all the way in. Follow the docs and the best practices first. Besides, manage.py is just like having a well-developed kit of shell scripts/ in your repo.
That is a reasonable price to pay for the batteries included approach.
What I am saying that I do not grok the big picture of Django flow.
For some reason I got up to speed with Laravel much faster and I do not write much PHP.
The books that I skimmed (like recommended Two Scoops of Django) just go into various things you can do but do not show the big picture.
So
appconfig/urls.py depends on
yourapp/views.py which renders html using a template at
yourapp/templates/sometemplate.html
Leaving that aside, async is very advisable (even a must) if your backend throws requests against external and potentially blocking services and you want to keep answering your own clients without scaling for no reason.
More aptly, if one can throw another physical server at it, is it worth fixing the underlying performance issue?
Sometimes the answer is yes. If you're at a place with even a thousand physical servers running your process and you can save 2% overall performance with a rewrite, that's saving you 20 physical servers worth of performance.
But often the answer is that it's not worth it. That 2% performance increase on a set of 10 servers is not calculable, and more often even a 10% performance benefit is only noticeable on some specific task, not as a constant overhead.
On the other hand, developer time is expensive and can often be best spend on core functionality.
If Django is, let's say even 20% slower than an async framework like FastAPI, but it's going to save three developers a week of development time to implement a feature in Django, then that's probably a much cheaper solution.
I've used Django, Flask, Sanic and FastAPI[1] and today I often choose FastAPI for my projects, but I think Django is still what I'd turn to if I needed to make a full fledged web application quickly, despite its performance not being as good as FastAPI.
[1] Before I learned Django, I also used Zope, and TurboGears.
Moreover, you're right to calculate this per year because maybe you'll throw this entire code away in a year, or maybe it will become the key code for something else, and you'll need to optimize it anyway.
Even sometimes having a meeting to discuss the performance is not cost effective. Six employees around a table for an hour discussing whether or not to improve the performance of 1200€ a year is not cost efficient.
But then again, sometimes it really is. In one environment we were asked to use some tooling on top of the OS that reduced performance by 5%. It was some management toy that would have made the Linux boxes do the same thing as the Windows boxes, but there was a performance penalty of 5%...
5% of 1000 machines is 50 machines, or just over one rack of servers, and so we could go back to management and say "The performance penalty of this is over a rack of machines. Are you sure you want this?" and then they can decide if it's worth it or not.
But yeah, some places have a very expensive acquisition procedure. To the point that the labor in buying expensive things costs more than the thing itself. But those places "solve" the problem by buying large batches, and the hardware x developer costs comparison don't change much.
If you have enough processes/threads running, the CPU scheduler should take care of that , no?
Django gets the shit done. There are plenty of developers to find for it. Lots of good quality plugins. Every problem you have, infrastructure wise, is often already solved and there is a blog post of it.
Its good parts and its bad parts are widely written about. And if that is not enough: the documentation is great.
Great framework to get your product to market, it allows me to focus on building products. I dont want to think about routing forms processing, or project layout again. I want to write code for the product, not for the framework. Django is just good enough. Forms, URL routing and models are not what delivers value to products I am working on. So I don't want to spend time on it.
Remember: no customer cares about your product being run on cool-async-framework-X. Customers just want a good looking and good working product.