Mostly agreed, though I would add that I'm generally happier with Python as a default for reasonably sized services that don't have a lot of (non-numpy-friendly) compute load and therefore don't have a pressing need for multithreading. Which is a lot of what happens now that we're all trapped in the cloud. Like you say, small apps tend to be easier in Python.

That is general take as well. A lot of small apps/simulators are in python. Ops scripts tend to be python. Java for the core/data. Refactoring/tooling is easier in Java when you are dealing with a 100k codebase imo. Typescript always.

Seen plenty of coding horrors in both ecosystems...

Algorithms are a lot easier to understand when they are written in Python. I'm actually right now documenting medium size Java codebase by writing pseudocode, which looks like Python. Just by doing that, I've already discovered multiple bugs, which I didn't catch by looking at the Java code.

That might be the big thing that I think gets glossed over in a lot of these discussions. I agree that I wouldn't want to maintain 100kloc of Python. But, I don't really view that as a realistic hypothetical for a business application. Idiomatic Python tends to require a fraction as much code as idiomatic Java to accomplish the same task. The only time it even gets close is when you have code written by people who go out of their way to make things look like old-school enterprisey Java. So it ends up accumulating a bunch of stuff like

  class IWantToBeABean:
    def init(self, arg1: int, arg2: str, arg4: str) -> None:
      self._field1: int = arg1
      self._field2: str = arg2
      self._field3: str = arg3

    def get_field1(self) -> int:
      return self._field1

    def set_field1(self, value: int) -> None:
      self._field1 = value
    
    def get_field2(self) -> str:
      return self._field2

    def set_field2(self, value: str) -> None:
      self._field2 = value

    def get_field3(self) -> str:
      return self._field3

    def set_field3(self, value: str) -> None:
      self._field3 = value

when it could have just been:

  @dataclass
  class IDontWantToBeABean:
    field1: int
    field2: str
    field3: str

The worse case for Python is when you get people doing the oldschool Python thing of acting like dynamic and duck typing means it's OK to be a type anarchist. Scikit-learn's a good one to put on blast here, with the way that the type and structure of various functions' return values, or even the type and structure of data they can handle, can vary quite a bit depending on the function's arguments. And often in ways that are not clearly documented. Sometimes the rules even change without fanfare on minor version upgrades.

The reason why large Python codebases are particularly scary isn't necessarily the size itself. It's that for a codebase to even get that large in the first place it's very likely to have been around so long that the probability of it having had at least one major contributor who likes to do cute tricks like this is close to 1. And I'd take overly verbose like the Java example above over that kind of thing any day.

Hey, you forgot useless comments for each method:

    get_field1(self) -> int:
      """
         Gets Field1.

         @rtype: int
         @return: the field1
      """
      self._field1

And use double underscores for private fields, because, you know, encapsulation.

Seriously though, in Java you don't need get*() either. Typically you either:

1. use `record` types (since Java14, 2020), or

2. use Lombok that auto-generates them [1], or

3. use Kotlin `data class`, or

4. just raw field access. I don't buy the encapsulation thing if my code is not a library for wide internet to use.

[1] https://projectlombok.org/features/GetterSetter

Try Kotlin then.

I wouldn't call it a new language, for me it's just a syntactic sugar over Java, but for any problem you would google "how to do X in Java", not "how to do X in Kotlin".

But there you can do way simpler syntax, like:

    0..100 meters with -45..45 deg within 3 seconds

Because "0..100 meters ..." is equivalent to "(0..100).meters(...)"

(0..100) is a built-in IntRange type, that you can extend:

    data class MyDistanceRange(val meters: ClosedRange<Double>)

    val IntRange.meters: MyDistanceRange
        get() = MyDistanceRange(first.toDouble()..last.toDouble())

and

IMO Kotlin has some features that take it way beyond just being syntactic sugar over Java. Like, I know you could probably use some eye-watering gang-of-four pattern to achieve the same effect as extension methods. But it's going to be such a PITA to maintain that calling the Kotlin feature syntactic sugar for the same thing is about as useful as saying that function definitions are just syntactic sugar over assembly language calling conventions.

I've played with it for a bit but it doesn't excite me enough to spend time learning it properly. I also don't care about Python beyond using it for learning algorithms and maybe some smaller Pyside UIs. However, together with Mojo it might become more interesting again.