[nrub]

You joking?

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

[jghn]

> strong typing

Python is a strongly typed language. Strong and Static typing aren't the same thing.

[rglullis]

You are obviously correct, but even if we let aside parent's confusion about strong/static typing, it's a weak argument.

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.

[OutOfHere]

In all the years I used Python at startups and firms, there always was extremely heavy resistance to using types correctly if even using them at all. Not one of the firms would have passed at even 80%. Moreover, me encouraging its use was always met with antagonism. In summary, Python types are a disaster for code comprehension and maintainability because they're optional. So you're right that Python has the tools, but wrong overall because you shouldn't be needing tools for something that should be a default.

[rglullis]

You are moving the goalposts. The point is that the abstractions exist. You can use them if you want and they will help you to build an understanding and managing complexity if you do.

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

[OutOfHere]

You are ignoring what actually matters on the job in the real world wrt code maintainability. It is impossible to get an LLM to correctly add many missing types since it's not clear at all what many of the types ought to be, and because different parts of the code have vastly different expectations (due to bugs) of the types. Should the LLM then support the bug or should it fix it -- it will never know for sure since it takes the code as a precondition. The vast majority of commercial Python code out there is truly horrible considering it is lacking type definitions and enforcement.

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.

[jghn]

> it's disastrous for code that requires development by a team

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.

[rglullis]

Not only your whole argument is pure conjecture, it's completely orthogonal to my original objection. People are just throwing completely silly takes as "python does not provide the abstractions to build and manage complex codebases" and this is demonstrably false. Let's just drop this line of discussion, because it's getting beyond ridiculous.

---

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

[two_cents]

you probably mean that python is not static typed.

[rglullis]

So, the abstractions are there, you just happen to think that the implementations are flawed or limited. This is not the same as claiming they are lacking.

[nrub]

No, they're not there. Did you read my comment? It's not just flawed or limited implementation, those are things that python just doesn't have.

[rglullis]

It absolutely does.

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

[simonask]

Not the person you replied to, but I think the point is that it isn’t really that interesting to point out that you can achieve certain things in Python with enough diligence.

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.

[rglullis]

There might be an argument to be made here, but this is a completely different argument than saying "python code is only readable locally" and "Python does not provide the abstractions to build and understand complex applications".

[arwineap]

As far as I know python type annotations are not enforced at runtime, these are really just helpers or extensions to your local dev environment

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

[rglullis]

> As far as I know python type annotations are not enforced at runtime, these are really just helpers or extensions to your local dev environment

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.