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

[fc417fc802]

I think both things can be true. Obviously a competent professional in any industry (not just software) can make shoddy or inappropriate tools work well enough. Obviously an incompetent or only barely competent or competent but pressed for time professional can screw up with even the most carefully designed highest quality tools.

But I also think it's clear that tool design impacts quality, safety, and efficiency. Programming languages aren't an exception to that.

[jghn]

> But I also think it's clear that tool design impacts quality, safety, and efficiency

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.

[OutOfHere]

Huh. If you're going to be blind to the science, then the team that you're in will continue to ship garbage code until finally one day they burn down the house. Feel free to bury your head in the sand, but don't drag us down with you. Preaching ignorance and apathy is what you're doing, and it doesn't relate with those who actually have standards and hold oneself accountable.

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

[OutOfHere]

Your original objection is altogether irrelevant. It and Python miss the point of what matters, which is the end result in teams. And I never actually said Rust; you did. Rust is not the answer to everything. It is easy to spot a religious zealot as you are for Python -- these people are the worst for the Python community as their blindness prevents from making the hard changes necessary for keeping up with the times.

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.

[rglullis]

The thread started with "Python lack abstractions to help thinking n large scale systems".

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.