[erokar]

> Python has problems scaling to medium-size code bases because programs above a certain size tend to become difficult to reason about.

In mye experience Python programs are not more difficult to reason about than equivalent Java programs. To the contrary an over-reliance on certain design patterns and ubiquitous, inescapable OOP complicates Java code bases, while the static typing is so weak it affords little safety compared to e.g. Python.

Worth keeping in mind a that a Python program will be about half the LOC of a Java program doing the same thing. (See the reference section here [1].) In other words you can get further with Python before passing the complexity threshold.

Bugs are also proportional to lines of code [2], which is another element that favours Python over more verbose languages like Java.

1. https://svese.dev/comparing-java-and-python-is-java-10x-more...

2. https://amartester.blogspot.com/2007/04/bugs-per-lines-of-co...

[klodolph]

There's a speculation in the first citation:

> Python is not maintanable above 50k to 100k lines of code and because of that people consider this code bases very large

Note that this is a speculation, not a conclusion, the article is not very thorough, and LOC is mostly used because it is convenient to measure, not because it is what we are trying to measure. I'd personally consider 50k a "medium" code base, and 10k is "small".

> Worth keeping in mind a that a Python program will be about half the LOC of a Java program doing the same thing.

LOC is a confounding variable.

> Bugs are also proportional to lines of code...

Not supported by the citation. The citation measures bugs per line of code, and finds that for 500 kloc of code, the average number of bugs will be somewhere between zero and 25,000. That's a very wide range.

To be clear, I'm not really trying to fight against Python or for Java here. I'm just giving my reasoning for why I might personally choose one or the other. I think that the idea that you would switch languages because Python is slow is actually far more situational. You might have ten reasons to choose Python or Java, runtime performance may only be one of those factors, it may not be heavily weighted, and in some cases, Python runtime performance can be extremely fast (I do a lot of NumPy stuff... it's great).

The relationship between programming language and code quality is, at best, a difficult relationship to study. It's hard to make any kind of direct statement like "using language X results in more bugs than using language Y" and back it up by evidence, even though we believe it to be true. Individual statistics which relate some variable to LOC is not useful in isolation.

See: https://arxiv.org/abs/1901.10220 (a reproduction of an earlier result, that invalidates many of the conclusions)

[kaba0]

> inescapable OOP complicates Java code bases

> while the static typing is so weak

Both of these are straight up false. Java can be written with static functions and single-depth inheritance trees just fine. Hell, the direction the language took for quite a few years now are pretty much this with records, pattern matching, etc.

And while Java is not Haskell, it has a moderately strong type system with quite a good generic implementation making even some more advanced functional patterns expressible.

Your claim on LOCs is also false (as well as most of this kind of claim) Java has at most a tiny bit of constant overhead, it won’t make it anywhere close to 2x.

[usrn]

This probably really depends on who you're working with. I think Go is a lot better at forcing people to behave than Python is.

[gosukiwi]

Forcing people to behave is the opposite of Python's approach, afterall, [we are all consenting adults here](https://mail.python.org/pipermail/tutor/2003-October/025932....)

[Spivak]

While this is something I very much appreciate about Python I think it's also true that structure needs to increase with the size of your codebase and the size of your team to avoid being driven mad. Python takes the "just apply discipline" approach which can absolutely work for lots of code but falls apart a bit with large heterogeneous teams.