Agreed. But I am not proposing a thread-per request model. The model will most likely be a fixed pool of workers, potentially combined with multiple processes, an M x N model.

I also agree that co-routines are cheaper than OS threads if the application itself is mostly waiting for network I/O. My question is what happens the moment the workload isn't purely I/O bound.

Right now, the solution seems to be an escape hatch where CPU-bound work is executed behind a thread-pool - see FastAPI or Starlette for example.

With free-threaded Python, I am interested in whether a framework can instead own that complexity: application code remains synchronous or async-partially (at the main thread).

> Removing GIL has nothing to do with that

It doesn't make network I/O faster, agreed. But, the more interesting consequence of removing the GIL is that with threads we can actually parallelise for CPU-bound Python code which earlier required multi-processor.

> How is it different from Flask or Django

This is probably the most important question. It's still in beta, so a lot of things can change. But simply put that Flask/Django lets one write sync code but do not provide the execution model I am describing. Concurrency is supplied at the server layer - gunicorn workers, etc.

The thesis that I am proposing is a framework runtime where concurrency and parallelism are first-class primitives. Now, that free-threaded makes threads capable of CPU parallelism can the framework own the concurrency and parallelism while application code stays async.

If you don't have co-routines, you need to have something else. That "something else" is most commonly threads, and each thread has non-trivial overhead, in scheduling and memory. A coroutine is much more memory efficient.

Removing GIL has nothing to do with that, coroutines are even worse re GIL problems. And of course, there are plenty of thread-based frameworks for Python, already - Flask and Django are most well known examples, but there are tons of others.

So my first question for author would be: "how is this different from Flask"?

Tbh we need to do some real research about it, because all those articles are just feelings that it seems to work better. But mostly it feels better, because we got stronger models and improved agent harnesses

If I recall the primary issue was the forced loading of the django settings file by otel.

I get that fully automated instrumentation should be turn-key and the current approach kinda works on basic applications.

But most production django applications are monoliths and generally larger apps. They have non-trivial configuration processes which are often multi step and source settings from multiple places.

Otel should not assume it can just randomly load a the django settings at an arbitrary time point in the startup process.

In one of our apps the MIDDLEWARE setting specifically is dynamically generated and re-ordered based on enabled features. That application's startup process also has multiple stages and the initialisation of django occurs much later, after dependant config loaders etc have been initialised.

What would allow us to integrate with opentelemetry-instrumentation-django much more easily is a set of smaller primitives that we can configure and call at the appropriate time.

opentelemetry-instrumentation-django has (had?) a lot of logic hidden inside a large "inject" function which could not easily be extracted into the constituent parts and applied in a compatible manner.

https://github.com/open-telemetry/opentelemetry-python-contr...

The only choices you get is full auto instrumentation, which breaks most non-trivial apps, or zero assistance/documentation.

There is no in-between where I can inject the functionality required in a way that is compatible with the application.

Just vibe code a vanilla Django app. No front-end frame work. No mobile app (just use your mobile's browser). Basic security baked in. It can handle 100k traffic a day easy which is 99% of small to medium businesses.

There are hundreds of cheap, easy to use hosting providers out there now (an LLM can figure out how to use). Or self host on a Raspberry Pi if you are slightly nerby (there are hundreds of videos on YouTube about it). Hit a technical hurdle: LLM will fix it.

Can't figure it out yourself, just throw a couple grand at a recent graduate to drive the LLM for you. There are tens of thousands who would do it for the experience on their CV.

SaaS is dead!

Oh no, what are we hiding?

> introduces bugs you already fixed.

Isn't this why every bug fix gets a unit test?

I appreciate rewrite isn't always the answer but it's a strange post when the authors should be giving constructive ways forward so we move to Rust and then use their 1k star Django clone they link to.

Instead anytime a question is posed it falls back to "sometimes" and little detail after that.

Citing a nine year old paper instead of something newer or doing their own benchmarking wasn't ideal either.

I wanted to see how far I could push that toolset. It worked surprisingly well. Django's capabilities meant such things as multi-user login pages, access controls and remote monitoring were very easy.

Anyway, it is a basic practice of keeping test and dev environment as close as feasible to production, to avoid missing issues and wrong assumptions.

Just the other day, I got Fable to help generate a sign-up flow for a Django app. It looked perfect to me, and like the Twitter post linked to, I looked at it with marvel and delight. But I got Sol to review the code and it spotted some fundamental issues with the flow that would have let bad actors enumerate accounts and log in before their account was verified - both of which were supposed to be checked.

To continue with the analogy, yes we can "will houses into existence", but unless we've checked the bricks and the foundations, these houses can easily crumble into rubble.

> https://www.postgresql.org/docs/current/sql-createtable.html

Unironcally, yesterday i was vibe-coding a small app for personal use using Django and was quite shocked to discover that Django's orm does not support something as simple as specifying a database schema other than the default "public" one out of the box.

You either have to add options specific from libpq:

    DATABASES = {
        "default": {
            "ENGINE": "django.db.backends.postgresql",
            "NAME": "mydatabase",
            "USER": "myuser",
            "PASSWORD": "mypassword",
            "HOST": "localhost",
            "PORT": "5432",
            "OPTIONS": {
                "options": "-c search_path=myapp,public",
            },
        }
    }

    ALTER ROLE myuser
    IN DATABASE mydatabase
    SET search_path = myapp, public;

Senior Full Stack & AI Engineer with 11+ years of experience designing and scaling enterprise web applications, microservices, and AI/LLM integrations (LangGraph, MCP, custom RAG pipelines). Strong background across React, Node.js, Python, TypeScript, and AWS cloud infrastructure. Experienced in leading full-stack projects, optimizing backend performance, and deploying production agentic workflows. Open to remote senior or lead full-stack / AI engineering roles.

Thank you for this advice. I can absolutely see how such advice could be helpful, and considering I have created environments (containerized) where that is not always possible, then that might explain some of my past results. XD

Do you have any advice on how to make LLMs actually follow instructions and how to prevent them 80/20-ing every task?

By the way, I appreciate you taking the time to reply. Thank you for you current and past contributions, I had a lot of fun with Django when I was in college.

Python backend engineer (~3 years), focused on AI integrations and MCP.

Open-source you can check right now: - b2b-enrichment-mcp — MCP server that unifies several external APIs (Hunter, Apollo) behind one interface, with retries and error handling. Listed in awesome-mcp-servers. - crosspost-mcp — an AI agent that publishes content to 5 social networks through a single interface. - lead-list-cleaner — a Python CLI for cleaning and deduplicating data, with tests, MIT.

I build backend services and LLM-powered agents, integrate multiple providers, and use Claude Code / Cursor daily. Comfortable with async communication (written English is strong, spoken is limited).

The term we are looking for here is something that means:

"A piece of technology that has been around for long enough that all of the sharp edges have either been filed off or are well documented and understood. We would not be the first people to solve our particular problem using this stack - in fact we would be using it in a predictable way that many before us have already shown to work. It's widespread enough that many people already know it, both on our existing team and in the pool of people we might want to hire from. We won't get to show off about this - our usage of this technology will not become the thing of legends, or conference talks, or blog posts. Our problems require unique solutions in other areas, but for the bit that accepts incoming web requests and runs some queries against a database we can go with something that's low risk, well established and very unlikely to surprise us."

I think boring is a fantastic shortcut for that, especially if you can trust your collaborators to understand it to mean that.

If you can't trust your collaborators to understand that then sure, you need to find a different word.

A couple of decades ago I helped create Django. One of the achievements I'm most proud of is that Django has graduated over time to being one of the most clear examples of a "boring" technology - it's widely used, stable, reliable, and thoroughly understood.

I agree. Simple and effective.

I would add a third small machine to give HAProxy a third vote. The problem with only two machines is that, if communications between them fail, you don't want both believing the other died and doing the wrong thing. You could use that third machine for Postgres backups, which would be smart because Postgress replication is not the same as backup.

Adonisjs has existed for more than 10 years. I’ve used Django for many years and I find Adonis way better (and ages more modern) than Django.

But .... if you run a multi cloud hybrid setup with kubernetes, service mesh, data [lake|pond|ocean] and millions of other fancy words in tech at each and every layer, you resume would look so awesome and you sound wicked smart. And the VP gets 600M budget for AWS and 600 developers, SREs, DevOps, PMO. It is not that things won't run, humans have perverse incentives.

I'm certain a lot of porn/adult industry run their setup like I mentioned with a Romanian dude running the entire infrastructure for $15K - $20K.