4 ms·
+1 Would be cool if some experienced dev could share some estimates when the Python scaling issues start. When you build a backend using Python + Django/FastA
by ck_one 5y ago
+1
Would be cool if some experienced dev could share some estimates when the Python scaling issues start.
When you build a backend using Python + Django/FastAPI, I assume in most cases the DB and not Python is the limiting factor. Moreover, you could always spin up more workers to mitigate scaling issues.
When you train ML models, your Python code just calls C++ functions. Python is not a limiting factor here either.
- ferdowsi 5y agoI worked for a startup that built their services using Python and Twisted. The codebase was a monolith broken up into several Twisted services, by the time I left it was probably 200k LOC of Python. For us, the scaling problems started when we had two independent teams working in the same codebase. The extreme dynamism of the language meant that classes and data structures were being mutated willy-nilly in ridiculous ways across the execution flow. The lack of static typing made onboarding new developers difficult as they had to parse generations of excessively clever code and magic left behind by departed developers. This problem has only gotten worse in Python 3, which keeps piling on more ways to accomplish the same task. The deployment story was also awful, but I don't think that's a surprise to anyone who has deployed Python at scale. In terms of raw performance, at one point we estimated that our Python stack was adding 3-400ms of request latency compared to a comparable system written in Go. With the Python 3 deadline coming, we convinced management to invest in rewriting performance-critical parts of the service in Go, instead of the migration to Python 3. I left before the project was completed but we were already seeing massive improvements.
- deleted 5y ago[deleted]