grandimam

This feels more like we are moving towards a Bun-like model where tooling becomes a unified runtime experience, handling everything from dependency management, package, linting, type checking and finally execution. To me, merging uv, ruff, and ty seems like a natural organizational step.

My heuristics is that the first 100 users are almost always a distribution problem. If you do not have 100 users using your product extensively, and you see a retention drop there is no way you can conclude anything else.

The reason why I take this approach is that - I have had personal experience building tools that didn't go anywhere, and same tools built by people with some online following gaining good traction. It could simply be a case of anecdotal experience, but distribution has always been harder for the tools I have built.

And would you share those recordings on YT or X itself?

I had created something along the same lines - a platform for devs to understand Python deeply, and was trying to see if there was a market for such content. The thing that I realised is that even with AI, there has to be distribution available for things like this to gain traction.

> each thread has non-trivial overhead.

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.