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

Business needs can be met in the short term only so long as the original developer of the project stays in the team. As soon as they leave, when excellent type definitions and annotations are missing, the project terminates because it's simply unmaintainable. I have seen this happen countless times. In other words, the deliverable will in the short term fool many clients who don't know better, but it is ultimately a scam.

[fc417fc802]

You're saying two different things there.

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

[jghn]

> I can hammer a nail with a rock well enough in a pinch

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.

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

[OutOfHere]

For the record, what I stated is fact, not opinion. Python is a fine language for the disciplined lone developer, but a terrible one for most teams. And it is not up to you to suppress this fact as you surely seem to want to do.

[rglullis]

If you want to make the case that Python is too flexible and it does not have guardrails for less experienced developers and undisciplined teams, I'd agree 10000%. I'm still traumatized by my time working in an academic setting and having to make sense of some bioinformatics packages.

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.