| ▲ | martinald 9 hours ago | |
Problem is though Python is slow at runtime. May not matter for many use cases, but I've worked with a lot of startups that suffered terrible reliability problems because they chose Python (or Rails, or Node to some extent) and the service cannot handle peak time load without a lot of refactoring and additional app servers. Depending on your framework Python is at best ~3x slower (FastAPI) and at worst ~20x (Django) than asp.net on the techempower benchmarks, which maps pretty well to my real world experience. | ||
| ▲ | casper14 9 hours ago | parent | next [-] | |
Can confirm. Just finished load testing a FastApi service. Now the biggest selling point is that a lot of real backend never experience the level of load where this actually matters | ||
| ▲ | mynameisash 8 hours ago | parent | prev | next [-] | |
I don't spend a lot of time building services, but the last few I've done, I actually went straight to Rust. The downside is that it's quite slow to develop -- I probably don't have the knowledge that others do, but it seems that frameworks could really use some work. That said, I love that I can find and fix most my problems during development. Building a service in Python means I'm constantly fixing issues in production. .NET is certainly better than Python, but I'm not very happy with the type system and the code organization versus my Rust projects. | ||
| ▲ | jtbaker 7 hours ago | parent | prev | next [-] | |
Not saying that it’s necessarily the right choice, but it opens up contributions to code to a broader user base and making those rapid iterations that tools like fastapi allow can be pretty important when proving out a concept early on. Horses for courses… also, a Horizontal Pod Autoscaler and Load Balancer setup is pretty cheap. | ||
| ▲ | WD-42 8 hours ago | parent | prev [-] | |
Most web apps are waiting on the DB anyway. Rarely have I seen the speed of the actual framework make any meaningful difference. | ||