Name one of those abstractions that is missing in Python.
- strong typing - real concurrency (heaven forbid you want a background task without having to spool up an external message queue and worker) - immutability - limitations in error handling (sort of just typing really) - limitations in nullability (also typing) - memory layout is usually hidden or abstracted away - no actual private methods or classes
That's far from a complete list, but maybe you're taking for granted the typical pythonic conventions that many practice. It requires a ton of work to design and architect python systems of any non-trivial size for maintainability and understanding. No language is perfect, but there are plenty of languages that make supporting complex systems easier than python.
- Typing annotations + mypy can completely help you build and understand a complex system. WIth pyright you can even analyze code that is not annotated. The tooling that enables developers to design and conceptualize their application around the type abstraction is there. You make it sound like people can write`x = "2" + 20` in python like in Javascript or PHP4.
- Concurrency: take your pick of multithreading, multiprocessing or asyncio. The abstraction of a thread model is there. The abstraction for an event loop is there. Would it be nice to have something like the Actor model as well? Sure, but to go from that to "python does not have it" is a completely wild take.
- "No actual private methods or classes": I mean, really? Obviously classes are supported. You can create different classes by composition, you can create a hierachical structure. You can use Protocol to define types that must implement interfaces. You can define functions that are overloaded and you can have method dispatching. All of these ABSTRACTIONS are provided. It's not because they are not forced on you that they don't exist.
Practical experience shows that languages that force some strictness about things that are known to be sources of trouble as complexity grows unsurprisingly make it easier to manage those sources of complexity.
It is vastly easier to write a performant, multithreaded program in Rust than it is in Python. That doesn’t mean it is easier to write all programs in Rust than in Python - it isn’t.
It's interesting to me that Python requires third party tooling (mypy) but we are still giving credit to Python that it has all the tools it needs
Yes, complex systems have been built in Python but that's despite it's tooling not because of it
Our python applications are all mypy, and we have been experimenting with the uv solution as well. I'm glad that Python has type annotations and classes but it sure doesn't feel the same as a statically typed language
But it is still a feature of the language. Try running a type-annotated python module on a python 3.4 interpreter, it won't work.
> but it sure doesn't feel the same as a statically typed language.
Again, that is totally a defensible position but an entirely different argument than the ridiculous "Python is only locally readable and does not have the abstractions to help understand large scale applications" line.
I am not here to make a case that Python is the ultimate language and that it is without flaws. Quite the opposite. I am porting some of my FOSS projects to typescript and Rust because I ultimately agree with the premise from the article. The only reason I am here in this stupid discussion is because it's 2026 and we still have some pretentious know-it-alls who think that Python is just some "scripting language" which can not be used for serious work.
Python is a strongly typed language. Strong and Static typing aren't the same thing.
Python does provide type annotations and extensive tooling to make static analysis, so this whole "missing abstractions to help with understanding" is simply false. You can even setup a python project to make annotations mandatory.
There are plenty of things to criticize about Python - performance, packaging and multiplatform distribution come to mind - but to think that it is missing the tools to help build and understand complex codebases is frankly absurd.
If you inherit a complex-but-working python code base and you think that types would help you, getting an LLM to add type annotations and enforce checking is certainly less work than "rewrite it in Rust".
Plenty of teams in startups will ignore automated testing as well, it does not mean that python is lacking the tools for it, nor does it mean that a hypothetical language that mandates 100% test code coverage would be better to "build understanding" or "managing complexity".
I rarely actually care about tests if the code is written clearly and with good logging.
Python doesn't enforce discipline, so anything goes. While this personal freedom is good in a religious sense for one's own project, it's disastrous for code that requires development by a team. Some programming languages are just better than others for team development. I say this as someone who benefited from Python professionally for a decade.
There also are more unrelated severe problems with Python, e.g. no official container for no-GIL (free-threaded), thereby making real parallelism impractical.
---
The funny thing is, I mostly agree with the core premise of the article: shipping today a functional proof of concept in Rust is not that more difficult than doing it from Python, and Rust has become the default choice for high performance libraries, so one might as well just go all-in Rust. But this has a lot more to do with real shortcomings of Python (performance, packaging and multi-platform distribution) than "Python does not provide the abstractions to manage complex codebases".
Using your logic, someone could similarly argue that C is a perfectly fine language if used with appropriate tooling which checks for errors, but it would be a similarly bogus argument.
I am not saying Python typing story is perfect in reducing errors or making code safe, I am just saying that the abstractions to "help manage large scale systems" are there.
No talk about "the end result in teams". No talk about "adoption on startups". I just called out a ridiculous, demonstrably false claim and you for some reason want to completely redefine the discussion around your opinion.
If you want to make the case that some other language makes a better fit for a world where LLMs and people can work at the same time and need to deal with complex codebases, fine.
You can even make the case where language expressiveness is less desirable now that LLMs can deal with implementation details and "engineers" can go by simply with English and UML.
These would all be interesting arvuments and worthy of a conversation. But again, this has nothing to do with the original point of the discussion.
I think Python could be okay as long as appropriate tooling is aggressively added to the project right at its start, with strict CI enforcement. At that point it residually becomes a culture issue which remains poor.
You continue to argue over something that was not on the table. That tells me that you just have an axe to grind.
> At that point it residually becomes a culture issue which remains poor.
Ok, so we are clear that the language itself is not missing the abstractions. I guess that's all I wanted to hear. Thank you, we are done.
> Type-enforced languages seem to avoid this problem.
Right, we all know how typescript projects are known for their longevity and we all know that people working in typescript are doing it because of their exceptional care about the craft and concern about maintainability. It has nothing to do with employability or the fact that startups:
- favor agility and time-to-market over long-term maintainability (i.e, they accrue a lot of technical debt)
- are more budget constrained and less likely to have enough resources to focus on cultivating good engineering discipline.
- have to compete with everyone else to attact talent in the labor pool and can not all afford to choose a tech stack that is less popular.
- will have a wild variance in the quality of the average developer.
No, sir. None of this really is really important to understand why startup teams have crappy code. It's all about the choice of statically- vs dynamically-typed languages.
I won't speak for TypeScript since I don't have comparable experience.
Typing is like the vascular system of the code, and untyped Python code is like having progressively higher blood pressure. Other problems with the code don't mean that you get to ignore the high blood pressure -- it remains a major killer of projects. Typed languages have other killers.
You have nothing tangible to show. No success story about turning a project around by changing the stack from a dynamic to static-based project. All you have is this axe to grind, but no real solution to make things better.
On another thread you are chastising another poster for "ignoring the science". I'd suggest you take a good look in the mirror... you talked about how you worked on all these different companies, and how they all keep failing and how it could've been avoided if only they listened to you. I'm surprised you never considered that the problem might not be the language, but with yourself.
I did everything I could in my capacity to bring good practices wherever I have worked, but ultimately it's in the hands of the project lead which I wasn't. Almost always, the leads favor speed at all costs, typically lacking the experience to understand they're on a path of destruction.
I have indeed worked with statically typed languages, and they dramatically lower the surface area for what can go wrong. Your utterly dumb argument is like saying that just because everyone eventually dies, addressing high blood pressure is pointless.
Honestly, my experience over (mumbles) decades has been that this argument has been trotted out hype cycle after hype cycle for different paradigms and languages, and it's never really true.
Teams can ship totally fine with just about anything. Teams can find ways to fuck up just fine with just about anything. Nothing really adds an appreciable overall positive over other alternatives in a global sense. The hard parts are always the hard parts. Most code still winds up kind of horrific but yet "good enough" for whatever business purpose is being met.
Peoples individual tastes differ and change over time, so they may feel these claims are true. But the folly is in projecting it onto others.
But I also think it's clear that tool design impacts quality, safety, and efficiency. Programming languages aren't an exception to that.
Yes, to an extent. And it's also the case that it usually doesn't matter. And that's my point.
I have also been someone like GP poster who has declared that it's physically impossible to produce valid software with XYZ tool in a team environment. And yet, there are oodles and oodles of counterexamples in the real world that proved me wrong and it worked AOK for them.
Could they all have been better off using another tool? Hypothetically yes. But their business needs (or whatever) were met and thus disproves a claim it can't be done.
> it usually doesn't matter
This is what I'm disagreeing with. I can hammer a nail with a rock well enough in a pinch but extrapolating from that to "it doesn't matter if we save some cash by equipping our carpenters with rocks instead of hammers" is obviously wrong.
There's a whole continuum of less extreme examples of the same principle. The quality and purpose fit of your tools absolutely does matter but in the case of programming languages it's a bunch of nontrivial tradeoffs that vary from one project to the next so it's all quite fuzzy.
The original post to which I responded said "it's disastrous for code that requires development by a team". Anyone claiming that using Python in a production environment is "disastrous", or equivalent to hitting a nail with a rock, is being obtuse. It has and continues to happen all the time with no notable ill effects. It's not like these teams are using Brainfuck here, Python is one of the most mainstream languages in the world, and I don't think I need a cite to make the claim that many, many teams manage just fine with it.
When I said "it usually doesn't matter", i'm talking in terms of the most important metric for a team: are the business goals being met i na timely and cost efficient manner. And my experience has been that as much as I've been a zealot in the past claiming that this tool or that tool can't possibly achieve useful results, teams that do use those tools still manage to achieve their business goals. Meanwhile I could also look around and find plenty of teams using whatever the flavor of the week "ideal" tool is and find teams that aren't meeting their goals.
Now, in an absolute objective sense, is it true that some tools are better fit for some purposes than others? Of course. Is it true that some languages lend themselves to robust coding practices than others? Of course. But the world's not a vacuum, and one must do the calculus at a higher level because as I said, the most important metric for a development team is achieving business goals. Would adopting tool A over tool B (for any A, B) improve the business? That's when these questions get a lot murkier, and the relative advantages & disadvantages tend to drop into the "noise" category.
> It has and continues to happen all the time with no notable ill effects.
But that statement of yours is patently false. The ill effects of duck typing and extreme flexibility in the face of massive code bases and large teams are incredibly well documented at this point. Literally the entire driving force behind typescript is directly analogous to the situation in the python world.
You might as well claim that concurrent programming in C or manual memory management have no notable ill effects. Even if there are places where you think they make more sense clearly they bring lots of fairly serious issues along for the ride.
Can it cause bugs? Yes. Do teams ship production code that meet their business goals? Also yes. The former doesn't necessarily preclude the latter. And as long as the business keeps on trucking along, complaining about the bugs and headaches is just a matter of engineering sensibilities. Which I agree with fully and grind my teeth every time.
If the business proceeds along just fine, having the perfect temple of dependently typed, category theoried, memory checked, fuzz tested software may have turned out to just be a waste of money.
If, on the other hand, the business does not proceed along just fine because the team can't get anything done due to not being able to understand that a float probably shouldn't go into a variable that's supposed to be a string, then yes, you're right.