A lot of Java's verbosity isn't so much from the language, but from when the code was written. It happened to come to popularity at a time when big over-engineered Gang of Four-style design was hot. So you get a lot of code written in this over-engineered fashion where half the classes have names that end in DelegateFactoryFacadeMessengerImpl.

Some of it is the language too, but modern Java can definitely be reasonably terse. Record classes has done a lot for the language, so has lambdas and streams.

Java is still good for several use cases, which were popular at the time, or let's say much more code was needed. Now in the Enterprise world you have much better no- or low-code tools. But in large teams all of these public/private/protected key words are quite nice. Totally unnecessary for a small codebase. But Java with its great runtime, verbose patterns is great for web server applications in large teams. I would still use it as the foundation for a tech company, but not for the Fortune500 company that needs some customization. Where is no alternative where you can find people, and has the stable properties. Maybe Rust if you have the clout as a company. Otherwise it's too expensive.

Protected data was never as useful to me as package-only data. The former is only relevant with inheritance hierarchies, whereas the latter is more open while also restricting access only to other classes in your com.example.concern package. Extremely useful for keeping big teams on the right track.

Yeah I think the problem is better understood now than when Java was originally designed.

Modules/Project Jigsaw is arguably an even better step in the right direction. It arguably allows a much saner granularity of visibility and access.

For its warts, Java was supported by a company with a lot of smart engineers who were working to provide a “batteries-included”, cross-platform language ecosystem and Sun was really invested in its success. I’d love to see some of these successor languages get the same kind of corporate sponsorship, but I don’t think it’s profitable.

The example they give later in the article is also pretty verbose and includes much more "magic" than Java

Example:

  import antigravity

  def main():
    antigravity.fly()

  if __name__ == '__main__':
    main()

I would argue that there is nothing simple about the last if-statement and will probably be very confusing for new developers.

> I would argue that there is nothing simple about the last if-statement and will probably be very confusing for new developers.

The only thing that isn’t perfectly straightforward is “what is __name__”, but once you know how __name__ is defined…

OTOH, that example is much more complicated than needed. As a simple executable script, that would do the same thing if antigravity. Fly() actually did anything, all that is needed is:

  import antigravity

  antigravity.fly()

The rest is unnecessary boilerplate to provide a module that can operate either as a library or a script, which is superfluous here. Moreover, since the actual functionality it is demonstrating is all in an import hook, all you actually need (the rest just produces an error message) is:

  import antigravity

> Apart from the call to write instead of print everything else there is a standard Python pattern for writing testable, type-safe arg-parsing code!

Its…not, actually. A more typical, and testable, example of python would be:

  import sys

  def main(args: list[str]) -> None:
    sys.stdout.write("hi\n")

  if __name__ == "__main__":
    main(sys.argv)

Your version:

* Isn’t testable because it runs the sys.exit() call unconditionally on import, so there is no way to import the module and call main() from test code.

* Fails with an error, because main has a required argument that it isn’t supplied in the unconditional main() call inside the sys.exit() call.

* Isn’t following a typical python idiom by returning a value from a function and have it be unconditionally 0; if the only options are a fixed return and a exception somewhere, the convention is to return None (which doesn’t require an explicit return.)

* Since a normal exit is the default response of ending the main program, sys.exit() is unnecessary here; “Exit with 0 if main() returns successfully, and with an abnormal exit on exceptions in main” is achieved by just calling main() and having nothing after it in the main program.