What's weird to me is that other languages have the exact same ability to suffer from this problem, but for whatever reason, they do not. Only Java seems to have this culture of circle jerking around patterns and idioms rhat solve problems you probably aren't or are never going to have.

> What's weird to me is that other languages have the exact same ability to suffer from this problem, but for whatever reason, they do not.

When you search long enough, you'll come across such programs. Even golang that's (falsely in my experience) claimed to be concise, I've come across monstrosities written in it. If you want an example in Python, look at gsutil's or gcloud storage's implementation and try to find how many levels deep you have to dig in to find out which gateway API call they make to do the actual transfers for commands like `cp`. The fact that Python has no types (yes type hints don't get you far) makes it a much more difficult task than if you're using a static language to navigate the code base.

And agreed on the Python thing. The lack of types can make debugging very painful. Also the overuse of Dict/arrays with no clear indications of the shape or keys can be brutal

1. Google prefer Kotlin over Java for Android.

1. You're old so your opinion counts for less.

6. On the stackoverflow survey Java is less wanted than APL, bash and CSS.

2. Go has a cuter mascot.

3. Java just copied from Javascript's name as an easy way to gain popularity.

5. OOP hasn't been cool since the 90s.

(Some of these things might not be true but if you're just looking to argue pointlessly, I think they'll do)

2. I’m young, and I also think Java is a great blue-collar language for long running projects

6. Stackoverflow is biased, some languages have great presence there, others prefer different platforms. Also, many of the “low hanging fruit questions” for java has been answered and are replicated all over the internet, so there is not much need for beginners to post Java questions anymore.

And that's fine, fight for Java in your life because that's your mastered ecosystem.

Trying to argue which tech stack is best is a pretty annoyingly dead and unanswerable question. There are a few quantifiable-ish things like you mentioned (hiring pool, tooling maturity, etc) but everything else gets subjective and meaningless pretty quick IMO.

The biggest concern for me and my shop is stability over time. We pick tools and vendors that can comfortably support B2B software contracts that are 5+ years long.

I see much more abandonware for Python and Java.

I have been working on 2 mil. LOC C# written by more than 100 developers over 15 years and it is really good experience.

>but they have revamped C# libs/platform so many times I have lost count.

What exactly do you mean? There was big migration towards .NET Core but full .NET will be supported forever. They even listened customers regarding WCF and helped a lot with CoreWCF.

Oh and on top every major dependency being a copy of the java’s version, and only the microsoft version will be remotely maintained. But please do correct me if my flamewary knowledge on the topic is not accurate.

The main reason is that it's effectively impossible to isolate code without physical separation. The upshot is that you end up heavily reliant on testing and byzantine development processes to keep your head above the water.

That's partly the reason why ideas like micro services have caught on. They offer the physical separation and they can have advantages that aren't easy to get elsewhere e.g. redundancy. But they also add a lot of overhead and complexity, which is fine if you're using them for their advantages, less so if you're using them for deficiencies in your language.

So, I too would argue that Java is a better language than Python for large scale system development. I wouldn't necessarily say it's the best, as other languages are often better in specific circumstances, but Python is pretty poor for big software.

Source: a lifetime designing, building and maintaining large and very large systems in Java, Python, C++, C#, Smalltalk, APL, and various niche languages that have disappeared into obscurity.

If I'd have to chose two reasons to answer your question, I'd pick up lack of static typing and relatively slow performance. Both can be alleviated (by things like MyPy, PyPy etc.) but it's not built in. You can build larger projects in Python, you just need more discipline and be realistic about potential bottlenecks.

Also, there's a HUGE overhead that comes from wiring together and maintaining the runtime environment. The extra hours that you need to spend to find the exact combination of frameworks, servers, JDK version, etc to just get the project to run is something quite unique to Java. And then you need to keep it all up to date and secure. Sometimes those hours are justified, but they can definitely be a factor when you are determining the best language for some particular project.

That is absolutely false. There is a huge list of already existing high-performance projects written in Java, used from HFT to distributed computations. Code using primitives (and thus actually comparing apples to apples) JIT compile down to just as efficient and performant code as what you would get with C. Applications reliant on dynamic allocations may very well come out ahead low-level languages due to its killer GCs vs mallocing left and right. (And no, not everything is replaceable with strict nested lifetimes a la Rust, and (atomic) reference counting is slow as hell. Nor is everything replaceable with arenas).

> Also, there's a HUGE overhead that comes from wiring together and maintaining the runtime environment

Do you even talk about Java? You literally just download a jdk and run the program. That works for 90% of the time (you can literally download 20 years old jars from some long-dead university professor’s website and it will just work). There are minor nits, but if you use the same jdk version it was meant to be used with it is literally dirt-easy. I don’t see how dynamic libs dependency hell is any easier to manage.

Where Java will never be seen: - equipment in hospital operating rooms - aircraft flight control systems - anywhere where you need clock cycle level precision (e.g. scientific measurement) - any system where there can be inopportune moments when garbage collection absolutely can't start

You mentioned speed of dynamic allocation. First of all, there are standards which prohibit any kind of dynamic memory allocation. Car computers are a popular example. Second of all, what do you think JVM uses under the hood? Magic?

That last paragraph kind of suggests to me that you have never needed to develop any kind of large Java EE project. For any team that I've worked with, it has usually taken from weeks to months to first research and then configure an acceptable stack that actually plays well together. Think Apache Web Server, JBoss (that shipped with some version of Hibernate), DB connection pooling, all kind of caching, dependency injection, interfacing with the outside world, web frontend tech, socket connections; and whatever build tools happened to be in fashion at that time (mvn, gradle and there plugin ecosystems). And then the truckload of XML that goes with getting it all to work together.

And then you have to sort out all the "The server JVM has run out of PermGen space", and "totally getting crushed under CPU load when the garbage collector decided to fire away at the worst possible instant", and the "weird exceptions under the hood that give you absolutely no clue why they are happening", and the "JNDI DB pool isn't releasing connections", and the "requests aren't getting distributed to workers correctly" and all the other fun stuff to work out. Usually when there are 10000 users hitting your service all at once, and after 3 hours of googling you find out that you needed to put ncvd:if="cfrog" instead of ncvd:fi="frogc" in mfnbooblah.xml, which by the way since version 47 or gobbldygook needs to be put in the app folder instead of the resources folder. Because that's obviously more betterer and enterprisier.

Do you even talk about Java?

Yes the runtime bugs me too, but I think your complaints are about dependencies in general, not just Java dependencies.

C# is just as good as Java on all accounts.

Rust is just as good as Java except the talent pool is yet growing.

C++ is just as good as Java except the language has no ceiling and the talent pool is shrinking.

This is automatic memory management’s greatest “gift”.

Garbage collection is over-valued.

CRUD in Rust is not as low-level as in C.

> making low level detail leak into its module contracts

There is the risk, yes. Design a good API, and it won't happen. Onboard 50 people who don't care, and you'll have all sorts of low-level thinking when it isn't appropriate. This is the risk of a language having no ceiling: Suddenly someone is spending the "novelty budget" without asking.

And I’m talking strictly about memory management here, sure Rust is a very cool language (it is my go to choice for low-level programming) and has a strong enough type system to actually make these refactors safe, but it doesn’t change the fact that this is simply of no concern with automatic memory management.

Java's GCs are superior to what C# offers by the way (and I like both languages).

You could say a similar thing for Erlang and its Dialyzer.

Yet other ecosystems manage.

The point I want to make is:

While that's an argument in favor of Java, it's not an argument against everything but Java.

Since 2016 .NET is running on Linux.

C++ should be something of a last resort, especially when you are given a choice.

I dislike its type system.

I don't know what all its wonderful tooling is.

Vendor support? The vendor (Oracle) will sue you.

JIT compilation produces fast code, so fast in fact, that it's only beaten by its one alternative - AOT compilation.

The JVM and its libraries are great, but I prefer the M.

Talent pool? People who are locked into it, like me.

Fair, it is not the best thing under the Sun (pun intended), but it is pragmatic and sufficiently strong (actually, with generics it is quite expressive, you can do almost everything besides actual Monads in it)

Come on, it has very good debuggers, you can get very detailed runtime data with basically zero overhead even in production, you can display the number of instances of all the objects and where were they created, and due to the language being uniquely big in both academia and industry it has so many niche tools that you can probably find everything for it. (You can literally statically prove a sort function with JML for example).

That Oracle part is just bullshit — oracle open-sourced the whole platform, made OpenJDK the reference implementation and there are more vendors available for that to choose from than I care to list. What other language can just go on as is if the main corporation behind it would disappear tomorrow?

Your sarcasm is not warranted regarding JIT compilation, for code that does the same thing it will be competitive with AOT compiled code.

And regarding talent pool, there are more java devs than people living in my country. I’m sure for every “locked in” one there is someone on the other end of the Gauss distribution.

> I don't know what all its wonderful tooling is.

Excellent refactoring tools by IDEs. Second to none profiling and monitoring (JFR, etc). Excellent debugging tools, profilers, etc.

Nothing else comes close frankly. C# it a not so close second.

OpenJDK is free. Oracle will not sue you.

Trying to detect nil pointer panics in go is a fucking nightmare. The compiler doesn't warn about it, and just lets it fly.

Browsers.

Games.