3 ms·

I have grown to believe that python is not appropriate for any organization where multiple teams will work in the same codebase / repo. The system is prone to d

I have grown to believe that python is not appropriate for any organization where multiple teams will work in the same codebase / repo. The system is prone to disorder and should be in the same category as perl for similar reasons. Programming is a team sport and static types is just too useful and the bolted on typing is insufficient. We are burning, literally, millions of dollars in salaries to make python work at our org. It has been the same now at the four shops I've been a staff/principal level. Dynamic languages lend towards less maintainable code because the compiler offloads work to your squishy human working memory.

seabrookmx 2y ago
mypy helps, but I generally agree. Similar thing on the node side.. Typescript is great but it's still a lot harder to scale an application. It can be done in dynamic languages obviously (PHP: Slack, Typescript: VSCode) but IMO it's harder. Despite having a big Django/DRF and FastAPI footprint, our backends in-development are using C#/aspnet.
TZubiri 2y ago
Yeah, but python services can work if they communicate by api with other services anyway. In essence solo dev: python is ok Tight teams: python not ok big corps where you literally can't even share code: python ok again.
krashidov 2y ago
Statements like these are usually too general to apply to every such case. But I think you are 100% right
r_hanz 2y ago
I tend to agree, the flexibility that non-statically typed languages (i.e. Python) offer on smaller-scale projects (very) quickly diverges to chaos on larger-scale. With scale, rules and rigidity provide structure, without they provide verbosity and bureaucratic obstacles. Unfortunately “scale” is a gradient, not discrete, so there’s no “right answer” - hence the waste you experience. Ultimately, waste is in the eye of the beholder… “One person’s waste is another’s GDP.”
treadmill 2y ago
> where multiple teams will work in the same codebase / repo This is a bad idea in general and leads to all sorts of problems.

seabrookmx 2y ago

mypy helps, but I generally agree. Similar thing on the node side.. Typescript is great but it's still a lot harder to scale an application. It can be done in dynamic languages obviously (PHP: Slack, Typescript: VSCode) but IMO it's harder. Despite having a big Django/DRF and FastAPI footprint, our backends in-development are using C#/aspnet.

TZubiri 2y ago

Yeah, but python services can work if they communicate by api with other services anyway. In essence solo dev: python is ok Tight teams: python not ok big corps where you literally can't even share code: python ok again.

krashidov 2y ago

Statements like these are usually too general to apply to every such case. But I think you are 100% right

r_hanz 2y ago

I tend to agree, the flexibility that non-statically typed languages (i.e. Python) offer on smaller-scale projects (very) quickly diverges to chaos on larger-scale. With scale, rules and rigidity provide structure, without they provide verbosity and bureaucratic obstacles. Unfortunately “scale” is a gradient, not discrete, so there’s no “right answer” - hence the waste you experience. Ultimately, waste is in the eye of the beholder… “One person’s waste is another’s GDP.”

treadmill 2y ago

> where multiple teams will work in the same codebase / repo This is a bad idea in general and leads to all sorts of problems.