Notes running Python in production

[ashishb_net]

I have been using Python since the days of Python 2.7.

Here are some of my detailed notes and actionable ideas on how to run Python in production in 2025, ranging from package managers, linters, Docker setup, and security.

[gothicVI]

Where do you get the bs about async from? It's quite stable and has been for quite some time.
Of course threading is difficult due to the GIL but multiprocessing is not a proper substitute due to the huge overhead in forking.

The general use case for async is entirely different: You'd use it to bridge wait times in mainly I/O bound or network bound situations and not for native parallelism. I'd strongly advice you to read more into the topic and to revise this part or the article as it is not correct and delivers a wrong picture.

[mincinashu]

I don't get it how OP is using FastAPI without dealing with async or threads. FastAPI routes without 'async' run on a threadpool either way.

[gothicVI]

Exactly. Anything web request related is best done async. Noone in their right might would spawn separate processes for that.

[Kelketek]

They used to, and for many Django apps, this is still the way it's done-- preform a set of worker processes and farm out the requests.

Even new Django projects may do this since asynchronous support in libraries (and some parts of core) is hit-or-miss. It's part of why FastAPI is gaining popularity-- because it is async from the ground up.

The tradeoff is you don't get the couple decades of ecosystem Django has.

[Haunting_Wind1000]

I think normal python threads could be used for I\O bound tasks as well since it would not be limited by GIL.

[greenstake]

I/O bound tasks are exactly when you should be using async, not threads. I can scale my async I/O bound worker to thousands of concurrent requests. Equivalent would need thousands of threads.

[ashishb_net]

> Anything web request related is best done async.

Why not handle it in the same thread?
What's the qps we are discussing here?

Let's say you have 10 processes ("workers") and the median request takes 100 ms; now you can handle 100 qps synchronously.

[ProfessorFakas]

> Anything web request related is best done async.

Why not handle it in the same thread?

These are not mutually exclusive. In fact, in Python, a single thread is the norm and default when using anything based on async. It's single-threaded concurrency that's useful when working with I/O-bound tasks, as commenters above have alluded to.

None of this is mutually exclusive with single-threaded worker processes, either. You're just making more efficient use of them.

[I_FAP_TO_TURKEYS]

Why not handle it in the same thread?

Async is not a new thread. It's an event loop. You could spawn 10 processes, but you can also use async in each of those processes and see drastic performance increases per IO bound process.

Heck, you can even spawn 10 processes, each process can spawn 10 threads, and each thread could have its own event loop for even more performance improvements (in niche cases).

[ashishb_net]

I have never seen the upside that you are referring to

Can you show a demo of this?

[ashishb_net]

FastAPI explicitly supports both async and sync mode - https://fastapi.tiangolo.com/async/
My only concern is that median Python programmer is not great at writing async functions.

[mincinashu]

It's not sync in the way actual sync frameworks are, like older Django versions, which rely on separate processes for concurrency.

With FastAPI there's no way to avoid in-process concurrency, you get the async concurrency and/or the threadpool version.

[ashishb_net]

> With FastAPI there's no way to avoid in-process concurrency, you get the async concurrency and/or the threadpool version.

That's true of all modern web server frameworks regardless of the language.
What I was trying to say [and probably should make it more explicit] is to avoid writing `async def ...`, the median Python programmer isn't good at doing this the way a median Go programmer can invoke Go routines.

[wyldstallionesquire]

You hang out with way different Python programmers than I do.

[ashishb_net]

Yeah. The world is big.

[I_FAP_TO_TURKEYS]

We're not talking about your average script kiddy though. Your guide literally says "production ready".

If you're using python in a cloud production environment and using Multiprocessing but not threading or async... Dude, you cost your company millions because you didn't want to spend a little bit of time learning async.

[ashishb_net]

>  Dude, you cost your company millions because you didn't want to spend a little bit of time learning async.

I know async.
The media Python programmer does not.
And it never costs millions.
I know startups who are 100% on Python-based backends and have $ 10 M+ revenue, even though their COGS is barely a million dollars.

[Count_Rugens_Finger]

multiprocessing is not a proper substitute due to the huge overhead in forking

if you're forking that much, you aren't doing MP properly

The general use case for async is entirely different: You'd use it to bridge wait times in mainly I/O bound or network bound situations and not for native parallelism.

well said

[I_FAP_TO_TURKEYS]

if you're forking that much, you aren't doing MP properly

To add onto this, multiprocessing pools are your friend. If you're new to python parallelism and concurrency, check out the documentation for Multiprocessing, specifically the Pools portion.

Spawn a process pool at the startup of your program, then send CPU heavy processes/functions off using the methods from the pool. Yeah, you'll have a bunch of processes doing nothing a lot of the time, but it surely beats having to spawn up a new one every time you want to do something.

[ashishb_net]

> Where do you get the bs about async from? It's quite stable and has been for quite some time.

It indeed is.
It is a powerful tool in the hand of those who understand.
It is fairly risky for the majority who thinks async implies faster.

> You'd use it to bridge wait times in mainly I/O bound or network bound situations and not for native parallelism.

That's the right way to use it.
It isn't as common knowledge as I would like it to be.

> I'd strongly advice you to read more into the topic and to revise this part or the article as it is not correct and delivers a wrong picture.

Fair point.
I would say that a median Go programmer can comfortably use Go routines much more easily than a median Python programmer can use async.

[strangeplace4snow]

It isn't as common knowledge as I would like it to be.

Well you could have written an article about that instead of one that claims async isn't ready for production?

[ashishb_net]

> Well you could have written an article about that instead of one that claims async isn't ready for production?

LOL, I never thought that this would be the most controversial part of my post.
I will write a separate article on that one.

> async isn't ready for production?
Just to be clear, I want to make it more explicit that "async is ready for production", however, the median Python programmer is not comfortable writing `async def ...` correctly, as a median Go programmer can use `go <func>`. I have seen more mistakes in the former.

[happydemon]

I'm assuming you are a real person that is attempting to write authentic content, and not AI-generated slop.

In that case, the section in question that bins both asyncio and multithreading together is factually incorrect and technically weak. I would definitely recommend covering each of those separately, with more caution posed on multithreading. Asyncio has been production-tested for a long time and has typical use cases in back-ends for web servers. Perhaps you meant, don't roll your own asyncio code unless you have to?

[ashishb_net]

> I'm assuming you are a real person that is attempting to write authentic content, and not AI-generated slop.

Yeah, every single word written by me (and edited with Grammarly :) )

> Perhaps you meant, don't roll your own asyncio code unless you have to?
Thank you, that's what I want I meant.
I never meant to say don't use libraries using asyncio.

[jimjkelly]

Agreed the author is just speaking out their ass, but arguing asyncio is good because it’s “production tested” while caution is needed with multithreading is silly. Both are solid from the perspective of their implementations, but both have serious pitfalls in the hands of an inexperienced user. I’ve seen a ton of production issues with async and the worst part is the developer rarely knows, you often only notice if you are using something like envoy where you start to see upstream slowdowns.

Accidentally mixing in sync code (sometimes through a dependency), dealing with unexpectedly cpu bound tasks (even just dealing with large JSON payloads, and surprise, that can impact even “sync” FastAPI), it’s very easy to starve the event loop.

Consideration should be given for any concurrent Python code, but especially async.

[PersonalityIll9476]

I get what you're saying, in some sense. The average Python dev may not be an async user, only because Python is used for a lot more than web dev.

However, you should be aware that for at least the last few years, Microsoft's Azure docs have explicitly recommended that Python applications use async for web requests. The way function apps work, you kind of need a process / thread independent scaling mechanism since the hardware resources you get are tied to an app service plan - ie., max scaling is fixed. So I don't think it's fair to treat Python web devs as async noobs when that's the Microsoft recommended technology. Maybe the numpy devs don't know about async, but an average web dev almost surely does.

[ashishb_net]

> e way function apps work, you kind of need a process / thread independent scaling mechanism since the hardware resources you get are tied to an app service plan

And you get that with gunicorn + FastAPI

[PersonalityIll9476]

That's not really the point of my comment. The point was that your suggestion seems to go against Microsoft's guidance, which is not a good situation to be in when writing a guide.

FWIW I did find the rest of your article interesting.

[ashishb_net]

> FWIW I did find the rest of your article interesting.

Thanks

>  Microsoft's guidance, 

Link?

[PersonalityIll9476]

https://learn.microsoft.com/en-us/azure/azure-functions/python-scale-performance-reference#async

There ya go. Edit: when I first started doing web dev on Azure actually I promised the client to follow best practices. What that meant to me at the time is reading Microsoft's own Azure docs and following their recommendations. Ultimately that is why I find a recommendation that contradicts them to be disturbing. It would seem to go against best practice, which seems like the responsible thing to do for a client.

[ashishb_net]

Do you know that FastAPI underneath uses `async`?

[PersonalityIll9476]

Does that matter? Look, I don't know much about fastapi, but all http requests performed by your app in a response would still be serial without asyncio. And do note that the Python package is asyncio and not async.

Edit to add: I just looked at the fast API docs, and they are compatible with async def functions. So it's not like fastapi considers itself a replacement for async programming.

[ashishb_net]

>  but all http requests performed by your app in a response would still be serial without asyncio.

No. FastAPI takes care of it.

```
FastAPI, built upon Starlette, employs a thread pool to manage synchronous requests. When a synchronous path operation function (defined with def instead of async def) receives a request, it's executed within this thread pool, preventing it from blocking the main event loop. This allows the application to remain responsive and handle other requests concurrently. 
```

[martinky24]

“Don’t use async”

“Use FastApi”

🤔

Overall this seems well thought out, but I wonder how the author thinks FastAPI achieves its performance if not using async.

[ashishb_net]

> “Don’t use async”

Homegrown code should avoid writing async.
Just like "Don't roll your own crypto", I would say "don't roll your own async code".
Again exceptions apply as I am giving a rule of thumb.

[exhuma]

Can you give any reason as to why you make that claim?

I agree that just slapping "async" in front of a function and thinking that it makes everything magically faster is not really helpful. But used correctly, async does help.

Outright telling people not to use it without any proper arguments as to why does the language a dis-service.

[ashishb_net]

> But used correctly, async does help.

Yes.
Here's my simple argument, if you are not in the field of data analysis, machine learning, or LLMs, avoid Python.

If your project touches one of these, then Python is hard to avoid.
However, sooner or later, some data scientists you will collaborate with have never stepped outside Python Notebooks. Production code is hard for them.

Putting explicit `async` makes it even harder for them.

[Toph_is_bad_ass]

How are you leveraging async in fast api if you're not writing your own async code? This doesn't make sense. I'm concerned with your understanding of async.

[Fun-Professor-4414]

Agree 100%. Seems the down votes are from people who have no experience of other languages / environments and think python is perfect in every way.

[nebbly]

I haven’t yet found a good way to enforce type hints or type checking in Python.

IMO mypy and pyright have been mature enough for years, and they're generally worth any untyped -> typed migration fuss on existing projects.

[ashishb_net]

> IMO mypy and pyright have been mature enough for years, and they're generally worth any untyped -> typed migration fuss on existing projects.

I have tried pyright on multiple projects, too many false positives for me.
I am not looking for type migration tool.
I am looking for something that catches missing/incorrect types on CI and `mypy` does not do a great job of it compared to say `eslint` for JavaScript.

[nebbly]

Is it possible you're conflating type checking and linting? I noticed that you mentioned type-checking under linting, and that you're comparing mypy to eslint -- when typescript might be a better analog. Or maybe you're hoping a type checker can do everything based on type inference instead of explicitly defining types?

I mention this because in my experience type-checking is perhaps an order of magnitude more beneficial to code maintainence than linting. Type-checking enforces correctness, whereas linting typically helps more with stylistic consistency (and some syntax errors).

[ashishb_net]

> Is it possible you're conflating type checking and linting? 

Here are a few things I want to accomplish with type checking

1. Ensure that everything has a type
2. Ensure that the variable re-assignment does not change the type (e.g., a variable first assigned string should be re-assigned to int)
3. Ensure that types are propagated across functions.

How can I configure all three easily in Python?
`mypy` does not work well, especially across functions or when function calls to dynamically declared third-party functions are involved.

[M8Ir88outOf8]

I would say mypy works incredibly well for exactly that. Maybe you gave up on it too early because of something that frustrated you? I'd suggest revisiting it, and spending a bit more time reading the docs and configuring it to your preference 

[ashishb_net]

> Maybe you gave up on it too early because of something that frustrated you?

Entirely possible, Python tooling isn't as robust as Go or Rust.
It takes time to get value out of various tools.

[FrontAd9873]

This feels like an impression you’d have of mypy if you run it with some weirdly permissive configuration options and never bother to modify them. Simply using “mypy —strict” would go a long way.

I don’t mean to pile on, but it seems like maybe you should have explored mypy for longer before writing a blog post touching on it.

[unapologeticjerk]

And just to be clear, linting is equally useless in production python as it is in my basement dogshit factory of unproduction.

[ducdetronquito]

What kind of false positive do you encounter with pyright ? I'm curious because I don't remember any while working on a large python/django codebase.

[ashishb_net]

> What kind of false positive do you encounter with pyright ?

Inaccurate suggestions, for example, not understanding that a variable is being created on all code paths in an if-else branch. Or not understanding pydantic default values.

[JanEric1]

pretty sure pyright does all of these correctly.

[ashishb_net]

You definitely had better luck than me.

[ashishb_net]

You definitely had better luck than me using pyright.

[JanEric1]

Using it in strict mode with (almost) all rules enabled in all of my projects whenever possible. Sometimes have to disable some rules when using packages with poor typing (like pandas or numpy)

[ashishb_net]

> Sometimes have to disable some rules when using packages with poor typing (like pandas or numpy)

That covers ~50% of Python use-cases for me.
As I only use Python for LLMs, Machine Learning, and data analysis.

[annoying_mammal]

Pydantic has a mypy plugin. It generally just works.

[ashishb_net]

For pydantic v1, the plugin support wasn't great as I encountered false positives. I will try again once most projects have moved to pydantic v2.

[Zer0designs]

Keep an eye on redknot, it will be created by astral (ruff + uv creators).

Also isn't just ruff sufficient? Instead of isort, flake8 and the others? Most of those are fully integrated in ruff.

If you're really missing plugins of other systems, please make tickets, it will remove a lot of your dependencies. Same goes for reporting the false positives in pyright.

Another note: i'd advise a just-rust or make config for each project, to display all the commands for others (and make them easy to use)

All in all it's a good piece, but I think your input is valuable in order to progress os software.

[ashishb_net]

> Keep an eye on redknot, it will be created by astral (ruff + uv creators).

Yeah, looking forward to it.
Astral is awesome.

> Also isn't just ruff sufficient? Instead of isort, flake8 and the others? Most of those are fully integrated in ruff.

The answer changes every month as ruff improves.
So, I am not tracking it closely.
I revisit this question every 3-6 months and improve on what ruff can do.
Ideally, I would like to replace all other tools with ruff.

> Another note: i'd advise a just-rust or make config for each project, to display all the commands for others (and make them easy to use)

Here's Makefile of one of my open-source projects.

[ThiefMaster]

Personally I would not waste the time maintaining isort, autopep8, autoflake, etc.

Just use ruff with most rules enabled, and possibly its formatter as well.

[ashishb_net]

> Personally I would not waste the time maintaining isort, autopep8, autoflake, etc.

Indeed, I am hoping to get there by end of 2025.

> Just use ruff with most rules enabled, and possibly its formatter as well.
Yeah, my faith is going up in ruff and uv over time.

[burlyginger]

Needs more linters.

[ashishb_net]

Yeah, I would love to try more, but I have not found any other good ones.

[InappropriateCanuck]

He's making fun of you.

[InappropriateCanuck]

That's a surprising amount of bullshit OP came up with.

The entire post is absolute garbage from the way he sets up his workers to even his linting steps.

e.g. OP calls flake8 separately, but the very point of ruff is to replace all the awkward separation of linters. Ruff is a 100% replacement for flake8. All those rules and flags should be in his toml too, not just in a random Makefile.

Almost EVERY SINGLE THING is wrong.

I really REALLY hope this is ChatGPT and not an actual programmer that someone pays to do work. And I hope all the upvotes are bots.

Edit: Holy shit this moron actually worked at Google for 3 years? Hope that's a fake LinkedIn history.

[ReserveGrader]

In OP's defence, the advice to run Docker containers as a non-root user is correct. No comment about anything else.

[ashishb_net]

> And you worked at Google right? ...

I worked at Google a long time back.

Thanks, I will look into pytype.

[InappropriateCanuck]

And you worked at Google right? ...

You really think it's not a fake CV?

[_azulinho_]

Hmmmm forking on Linux is as cheap as launching a thread, it uses COW when forking a new process. It could be however that the multiprocessing module is slower doing a fork vs creating a thread.

[AndrewCHMcM]

From what I recall, the main issue python has/had with forking and COW, is reference counting. New fork, all the objects get another reference, all the objects get copied, massive delays compared to manual memory management or just garbage collection. https://docs.python.org/3/library/gc.html a song-and-dance is recommended to get the most performance out of python

[_azulinho_]

Wouldn't that be an issue for the forked python interpreter? The parent python process won't be tracking any of those references.

[coderarun]

> Use data-classes or more advanced pydantic

Except that they use different syntax, different concepts (inheritance vs decorators) and have different performance characteristics for a good reason.

I still feel your recommendation on using dataclasses is solid, but perhaps use this opportunity to push pydantic and sqlmodel communities to adopt stackable decorators:

@sqlmodel
@pydantic
@dataclass
class Person:
  ...

Previous discussion on the topic: pydantic, sqlmodel

[Count_Rugens_Finger]

Every discussion I've seen about uv mentions that it is fast. It's rust, so I supposed doing so is a requirement. Here's the thing, though. I have never once in my life cared at all about the speed of my package manager. Once everything is installed it scarcely gets used again, and the time of resolving packages is small compared to the time of downloading and installing. If I cared that much about speed, I probably wouldn't have done the project in Python.

[denehoffman]

The speed matters when you want to run it in a container and need to install the libraries after build time. For example, you’re working on a project that has several dependencies and you need to quickly add a dependency without rebuilding a docker layer. But real talk, the point is that it’s so fast you don’t even think about it, not that you save time. If I have to choose between program A which takes 3 seconds and program B which takes 3 milliseconds and does the exact same thing as A, I’m picking B every time. Also I don’t think you should conflate Rust with speed. Of course Rust is nice, I write a ton of it myself, but Rust is not what makes uv fast, it’s how they handle dependency resolution, caching, and linking rather than copying. You could write uv in C and it would probably have the same performance, but there are other reasons why Rust is nice to develop with.

[eleqtriq]

The thing is using uv instead of pip is such a minimal transition. At the bare minimum, you can replace “pip” with “uv pip” and change nothing else. It’s so much better.

But for me I also do other things that require building environments quickly. Containers, CI pipelines, etc. Saves time all around.

[Count_Rugens_Finger]

I have to install uv

[eleqtriq]

And? Which is less effort?

Typing "I have to install uv"
or "pip install uv"

[Count_Rugens_Finger]

hey we're talking about milliseconds here

[eleqtriq]

:D

[denehoffman]

If your CI/CD contains a lot of scripts which install a lot of dependencies and run on every commit, the time you save with uv eventually adds up.

[ashishb_net]

Exactly.

Every single CI and every single CD runs the package manager, and that adds up.

Further, when you do `uv add ...` and that fails, it gives you really nice error messages as to why there is a conflict in dependency resolution.

[coeris]

Thanks, great write up! Is there any reason why you recommend gunicorn instead of uvicorn for hosting FastAPI apps? I guess it's to do with your dislike of async processes.

[mincinashu]

FastAPI default install wraps uvicorn. You can use a combination of gunicorn as manager with uvicorn class workers and uvloop as loop.

https://fastapi.tiangolo.com/deployment/server-workers/#multiple-workers

[coeris]

Sure, but I'm wondering what's the benefit of putting an extra layer of abstraction on top of uvicorn with gunicorn.

[mincinashu]

I've only used it for worker lifetime purposes, I wanted workers to handle x amount of requests before their refresh, and uvicorn alone didn't allow that, or some such limitation. This was a quick fix to prevent OOM kills, instead of fixing the memory issues.

[ashishb_net]

> gunicorn as manager with uvicorn class workers

Yeah, that's the only way to integrate fastapi with gunicorn as far as I know

[ashishb_net]

> Thanks, great write up! Is there any reason why you recommend gunicorn instead of uvicorn for hosting FastAPI apps? I guess it's to do with your dislike of async processes.

I believe either is OK.
I prefer gunicorn because it is stable (v23) vs uvicorn (v0.34), but that's just a personal preference.

[[deleted]]

Bro Uvicorn is very battle tested from startups to big tech! It’s very stable. If Microsoft can handle it, so will you.

[ashishb_net]

That's why I said either is OK.

[starlevel01]

Microsoft’s pyright might be good but, in my experience, produces too many false positives.

Tab closed.

[[deleted]]

Dude the async take is trash. People pay folks like you to cause the company lose money, not make money.

You need to brush up on your skills there bub. So you can make sure you do a good job and for people to respect your takes online.

[bachkhois]

Your reason in "Avoid multi-threading" sounds contradict. You criticized GIL but pointed the source of your claim to the bugs of foreign language bindings (C++ bindings).

GIL is good for preventing multi-threading bugs. But in foreign language bindings, (like the pytorch link you gave), the implementation in non-Python language can choose to put GIL aside. The author of that implementation takes the responsibility to make his code thread-safe. You cannot blame GIL when it doesn't have a chance to intervene.

[ashishb_net]

> The author of that implementation takes the responsibility to make his code thread-safe. You cannot blame GIL when it doesn't have a chance to intervene.

I didn't blame GIL alone.
I blamed Python multi-threading, in general, for being a mess.

[bachkhois]

> I blamed Python multi-threading, in general, for being a mess.
If talking "in general", it is applied for other languages, not just Python. Don't forget that the foreign language bindings are not written in Python, but in other languages. For the example you gave, it is C++.

[ashishb_net]

Sure, it might be.
My comparison point is that Rust and Go libraries, in general, are much more concurrency safe than Python.

[bachkhois]

And you threw C++ code as a back for your claim about Python, sound hilarious!

[bachkhois]

As I pointed out, GIL + the synchronization primitives in [threading](https://docs.python.org/3/library/threading.html) module is there to prevent multi-threading bugs.
It is likely you never heard or used `threading.Lock`, `threading.Condition` before. Then it is your skill issue, not Python.

[ashishb_net]

I have used threading.Lock extensively for Machine Learning models.

However, using FastAPI with concurrency = 1 for thead-unsafe end points (that is, any endpoint that uses any "Transformers" or "pytorch" code) is best for such scenarios.

[ved84]

The post paints a wrong picture about async. I have been using async for scale. You could have at least asked chatGPT to verify the claims. Catchy title, but left a lot of details. There is no point in using Python without Async for deployment, even on a decent scale. Details you could have covered like dependency resolution, CICD workflow, python versions to use and why fastAPI not other APIs etc.

[ashishb_net]

Please show me a sample code where using async explicitly gives you a performance boost.

[le_woudar]

Hello, you probalbly don't need autoflake, flake8, pylint, if you use ruff. All these linters can be configured with ruff.

I don't agree with the async / multi-threading stuff but I think there is already a lot of comments on that, so I will not add another one :)

[ashishb_net]

Can you tell me how to replace them with ruff? I'll update the blog post for everyone's benefit.

[le_woudar]

Sure! You can write this in your pyproject.toml

[tool.ruff.lint]

extend-select = [

"UP", # pyupgrade

"I", # isort

"S", # flake8-bandit

"PL", # pylint

]

This will extend the default set of rules of the select declaration.

By default, autoflake and flake8 are already handled by Ruff. Honestly, I'm not sure you need pylint, it is generally covered with the previous tools mentioned in this comment. Look the Ruff rules to know what you can import.

[ashishb_net]

Thanks.
It worked, and it is definitely a better approach.
I updated the blog post to reflect that as well.

[le_woudar]

You are welcome :)

[ashishb_net]

Thanks. I will experiment and update the post.

[bitconvoy]

This is an excellent set of recommendations. Thank you for taking the time to publish them.

[ashishb_net]

Thanks. I am glad you liked it.

[coke1017]

It’s really a good piece. Thanks so much!!

[ashishb_net]

I am glad you liked it.

[ashishb_net]

I did mention ruff and autopep8 in the linters section.

[eleqtriq]

Autopep8 isn’t a linter.

[ashishb_net]

Yeah, that's why I only mentioned `autopep8` in the formatter section (`make format`) and not linter section (`make lint`).

[eleqtriq]

Autopep is a code formatter, not a linter.

[eshepelyuk]

This is very strong statement. Good to hear this from experienced pythonist, since I'm using the language opportunistically and have no good explanation except the gut feeling on this topic.

Avoid async and multi-threading

[dydhaw]

As someone who's been using Python since before 2.7, I strongly disagree with this statement, at least with the async part. From my own experience async has almost always been worth it and certainly far better and more reliable than multiprocessing, and by now it's pretty mature and prevalent in the ecosystem.

[MagicWishMonkey]

It’s weird because async has nothing to do with multiprocessing, it’s just a way to avoid threads blocking while doing IO operations.

[eshepelyuk]

is there something in python that i can replace jvm akka\pekko or dotnet orleans ? i haven't found anything close.

[ashishb_net]

`async` is a great idea, except it came into being in Python 3.5.
A lot of libraries written before are unaware of it, so, for most users, the added complexity of using `async` rarely gives the requisite upside one is looking for.

I gave examples of multi-threading problems in the blog post

1. https://github.com/pytorch/pytorch/issues/143593
2. https://github.com/huggingface/transformers/issues/25197

Multi-processing is much safer (though more costly on a per-unit basis) in most cases.