Same experience working on FastAPI projects. I don’t know how big production apps are maintained (and supported operationally) with the mess that is python+async+types.
Conversely all the node+typescript projects, big and small, have been pretty great the last 10+ years or so. (And the C# .NET ones).
I use python for real data projects, for APIs there are about half a dozen other tech stacks I’d reach for first. I’ll die on this hill these days.
100% same experience. If it were up to me, I'd started with typescript, but the client insisted on using a python stack (landed on FastMCP, FastAPI, PydanticAI).
While, `PydanticAI` does the best it can with a limited type system, it just can't match the productivity of typescript.
And I still can't believe what a mess async python is. The worst thing we've encountered was a bug from mixing anyio with asyncio which resulted in our ECS container getting it's CPU pinned to 100% [1]. And constantly running into issue with libraries not handling task cancellation properly.
I get that python has captured the ML ecosystem, but these agent systems are just API calls and parsing json...
[1](https://github.com/agronholm/anyio/issues/884)
async python has problems, but "anyio exists" is not one of them that can be blamed on python, simply dont use weird third party libraries trying to second guess the asyncio architecture
edit: ironically I'm the author of a weird third party library trying to second guess the asyncio architecture but mine is good https://awaitlet.sqlalchemy.org/en/latest/ (but I'll likely be retiring it in the coming year due to lack of interest)
I don't recall the exact situation but am I suppose to just know which async library each dependency is using? It reminds of of the early days of promises in JavaScript.
I don't really see how you're comparing Pydantic AI here to Typescript. I'm assuming you meant simply Pydantic.
Just comparing an agent framework written in python (with focus on being "typesafe") to one (any) written in typescript
That's a very poor comparison then and not very useful?
>Same experience working on FastAPI projects. I don’t know how big production apps are maintained (and supported operationally) with the mess that is python+async+types.
In my experience async is something that node.js engineers try to develop/use when they come from node.js, and it's not something that python developers use at all. (with the exception of python engineers that add ASGI support to make the language enticing to node developers.)
But then how to you build a performant API in python if you don't use async? Do you give your API's giant thread pools?
Multiple processes, multiple threads per process, and/or greenlets (monkey patch network calls, like async but no keywords involved). Scale out horizontally when there's a problem. It could get expensive.
Async isn't about performance, the overhead it eliminates is small
You spawn a thread when you get a request
Yeah I did my first project with FastAPI earlier this year with experience in other languages and I couldn't believe how bad it was.
The funny thing is all the python people will tell you how great FastAPI is and how much of an improvement it is over what came before.
FastAPI does have a few benefits over express, auto enforcing json schemas on endpoints is huge, vs the stupidity that is having to define TS types and a second schema that then gets turned into JSON schema that is then attached to an endpoint. That IMHO is the weakest link in the TS backend ecosystem, compiler plugins to convert TS types to runtime types are really needed.
The auto generated docs in FastAPI are also cool, along with the pages that let you test your endpoints. It is funny, Node shops setup a postman subscription for the team and share a bunch of queries, Python gets all that for free.
But man, TS is such a nice language, and Node literally exists to do one thing and one thing only really well: async programming.
> That IMHO is the weakest link in the TS backend ecosystem, compiler plugins to convert TS types to runtime types are really needed.
Just define all your types as TypeBox schemas and infer the schema from that validator. This way you write it once, it's synced and there's no need for a compiler plugin.
https://github.com/sinclairzx81/typebox?tab=readme-ov-file#u...
That is nice and all, but it is one of many libraries that solves a problem that shouldn't exist.
The TS compiler should either have an option to pop out JSON schema from TS types or have a well defined plugin system to allow that to happen.
TS being compile time only really limits the language. It was necessary early on to drive adoption, but now days it just sucks.
Zod [0] isn't too bad for runtime types and runtime type evaluation. It even has JSON schema output now [1], though most of my API uses of Zod have been with Hono's "RPC" [2] which does a bunch of type magic to build a type-safe API client from your API types directly (in projects where you can share front-end and back-end types).
[0]: https://zod.dev/
[1]: https://zod.dev/json-schema
[2]: https://hono.dev/docs/guides/rpc
Maybe you have non TS clients, but I moved to tRPC backends and now my consumers are perfectly typed at dev time, combined with pnpm monorepos I’m having a lovely time.
What's bad about it?
Hell I write ETL pipelines in Typescript since it's just... way easier to deal with. Not doing any crazy ML processing. But the Node ecosystem is giant and I'm a huge fan of the ergonomics of Typescript. And since Typescript is so popular it's very easy for other developers to make changes in my code.
> Same experience working on FastAPI projects. I don’t know how big production apps are maintained (and supported operationally) with the mess that is python+async+types.
Very painfully.
I avoid the async libs where possible. I'm not interested in coloring my entire code-base just for convenience.
What's messy about python+async+types?