4 ms·

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+asyn

by davedx 1y ago

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.

cjonas 1y ago
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 https://github.com/agronholm/anyio/issues/884)
- triyambakam 1y ago
  I don't really see how you're comparing Pydantic AI here to Typescript. I'm assuming you meant simply Pydantic.
  - cjonas 1y ago
    Just comparing an agent framework written in python (with focus on being "typesafe") to one (any) written in typescript
    - triyambakam 1y ago
      That's a very poor comparison then and not very useful?
- zzzeek 1y ago
  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/ https://awaitlet.sqlalchemy.org/en/latest/ (but I'll likely be retiring it in the coming year due to lack of interest)
  - cjonas 1y ago
    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.
simlevesque 1y ago
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.
- com2kid 1y ago
  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.
  - simlevesque 1y ago
    > 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#usage https://github.com/sinclairzx81/typebox?tab=readme-ov-file#u...
    - com2kid 1y ago
      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.
  - 1y ago
TZubiri 1y ago
>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.)
- davedx 1y ago
  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?
  - jdsleppy 1y ago
    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.
  - TZubiri 1y ago
    You spawn a thread when you get a request
  - kurtis_reed 1y ago
    Async isn't about performance, the overhead it eliminates is small
all2 1y ago
> 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.
65 1y ago
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.
kurtis_reed 1y ago
What's messy about python+async+types?

by davedx 1y ago

cjonas 1y ago

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 https://github.com/agronholm/anyio/issues/884)

triyambakam 1y ago
I don't really see how you're comparing Pydantic AI here to Typescript. I'm assuming you meant simply Pydantic.
- cjonas 1y ago
  Just comparing an agent framework written in python (with focus on being "typesafe") to one (any) written in typescript
  - triyambakam 1y ago
    That's a very poor comparison then and not very useful?
zzzeek 1y ago
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/ https://awaitlet.sqlalchemy.org/en/latest/ (but I'll likely be retiring it in the coming year due to lack of interest)
- cjonas 1y ago
  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.

simlevesque 1y ago

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.

com2kid 1y ago
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.
- simlevesque 1y ago
  > 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#usage https://github.com/sinclairzx81/typebox?tab=readme-ov-file#u...
  - com2kid 1y ago
    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.
- 1y ago

TZubiri 1y ago

>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.)

davedx 1y ago
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?
- jdsleppy 1y ago
  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.
- TZubiri 1y ago
  You spawn a thread when you get a request
- kurtis_reed 1y ago
  Async isn't about performance, the overhead it eliminates is small

all2 1y ago

> 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.

65 1y ago

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.

kurtis_reed 1y ago

What's messy about python+async+types?