Progressively slower development seems like a pretty massive risk these days, where not being able to chase a competitor's big feature can be the death knell to your company.

Though it seems java in general attracts a culture of slow moving bureaucrats which doesn't necessarily translate into higher quality (in fact, I'd argue it translates into worse quality).

> Progressively slower development seems like a pretty massive risk these days, where not being able to chase a competitor's big feature can be the death knell to your company.

You are conflating to different layers. Not being able chase a competitor's big feature can be the death knell to your company, yes. But this does not mean that building your business software on stable and proven foundations is a high risk. On the contrary you want to be fast moving with your business features not with keeping up with quicksand under your feet. I.e. a stable well understood basis, is IMHO a prerequisite to moving fast above of it.

In addition to my arguments above, one still has to consider whether a tool matches the problem. Writing an Excel plugin in Java is probably a very bad idea (I really don't know, I just assume that anything based on .NET would be a better fit), although both Excel and Java value long term compatibility. If you want to follow the latest trends in AI without really understanding what is going on, it is probably best to follow all the tutorial about AI and use Python. But if you plan to hire people that understand the details of AI libraries, you might come to the conclusion that the AI libraries on the JVM also provide the basic blocks you need, the higher levels are customized to your application anyways.

To come back to the original point, a technology or programming language is not good if it moves fast, it is good when it fits your problem, doesn't create too many new problems, is well understood by you and your team and is maintained.

You're the one conflating my argument here. What I'm pointing out is this: there's somewhat of an assumption that java moves slow yet steady, therefore not generating the code mess other languages get blamed for, ending in either an undecipherable mess, or degradation of development quality and speed. The idea being that java makes one more likely to win the marathon in favor of losing the sprint. Whereas many other languages can only win the initial sprint, become messy, and then proceed to be unable to move with competitors anyway later down the line.

In practice, I've barely ever seen this assumption truly come to fruition. I see java codebases degrade, become undecipherable messes filled with reflection, inflate themselves to become incredibly hard to understand or work with, at similar rates. I still see JSPs throwing garbled stacktraces that barely help understand what's wrong. Still see business shoot itself in the foot because it said "this should never happen", so the code is made under the assumption it doesn't happen, because null is still available and no one uses optionals, and 2 months later you have clients show you another NPE after going through 15 layers of business-modifying logic and people spend a week uncovering how the situation can take place (or worse, it is retroactively sealed up and the actual bug is still there). If there's some magic spell that helps java become less messy than other static languages or even some dynamic languages, I have yet to see it.

At that point, one has to question: what are we losing the sprint for? Are we truly increasing the odds of us winning the marathon? Not even its most espoused benefits, libraries, write once work everywhere, etc., seem to be remotely unique anymore. The only two answers I see, are legacy, and the number of java devs available. Lose a java dev, no problem, just pop in another. Want to rewrite the app in a different language, or even in less verbose, modern java? Good luck convincing management firmly believing that a rewrite of one month is more costly than pushing out features at 1/10th the speed post-refactor for another 2 years.

And yet... That is what I got from a less than 2y/o Python application.

Java isn't the problem. People lacking a broader view are.

I highly doubt the progressively slower development claim.

I agree that Java is low risk from a manager responsibility perspective: nobody has been fired for choosing it for a long time.

Now, from a project success perspective, I think it's not. I've seen a lot of Java projects fail, over engineered, full of spaghetti code, riddle with inscrutable abstraction, stuck in a glue of badly designed architecture that has been fossilized by the type system.

I'd say from a project risk perspective, it's a pretty average language, it has pros and cons, but they balance each other.

I have seen a lot of projects fail over the years, for many different reasons, but I have never seen a project fail due to the choice of programming language.

> I've seen a lot of Java projects fail, over engineered, full of spaghetti code, riddle with inscrutable abstraction, stuck in a glue of badly designed architecture that has been fossilized by the type system.

Sure, but do you really think the same organization would have produced perfect simple elegant error-free code is Haskell or Smalltalk (or whatever "better" language you are comparing to) under otherwise same requirements, deadlines, resources and management?

I'm not saying languages doesn't matter. A better/more appropriate language is like having a bigger screen or a better chair. All else being equal, it will increase productivity and make developers happy. But it will not make or break a project. The things that will break the project: Bad/unclear specifications, bad management of change requests, lack of testing, unrealistic scheduling, lack of customer feedback, bad communication or conflicts among developers.

It's an anwser to "You use Java because it is low risk". I just don't think it's immune in any way.

Of course Java project are not immune to failure, that is not what "low risk" means! In this context it means the risk is lower for certain specific problems - e.g. unable to hire developers, show-stopping bugs in the platform which never get fixes, lack of documentation, abandonware.

Choosing a less popular platform (like say Clojure or CoffeeScript or whatever) might very well increase productivity compared to the conservative choice. But slightly increased productivity will not save a project, while the additional risks involved could very well sink the whole project. Which is why most businesses seek to reduce risk rather than maximize productivity when it comes to development platforms.

Imagine adding to the list of risks for a new project the term "low talent pool" and "head engineer leaving".

Many languages haven't been popular long enough to have a nice pool of experienced engineers to pick from. Java has that advantage, which not many languages have.

> Java projects fail, over engineered, full of spaghetti code, riddle with inscrutable abstraction, stuck in a glue of badly designed architecture that has been fossilized by the type system.

these are properties of a poorly designed project, and isn't due to it being java.

You may be able to causally link the failure to the people on the project being "incompetent" - but that's not really the fault of java!

i say java is a pretty good language, if you have large teams, with varying levels of competency amongst the members. As long as you have somebody good to do the overarching design and direct the project, it would do relatively OK.

if you have a small, elite team, then it may not be the right choice (depending on the team).

Well, law of big numbers. Java is used everywhere. For every failed Java project, there is many successful one as well. And honestly, chances are that team would have failed in any other language as well.

I generally agree, except the part about the low risk of runtime surprises. Java's type system is so weak that it doesn't even prevent null from inhabiting almost every type. The programmer is then forced to manually reason about when a value can be null or not, and of course humans can easily make mistakes in doing so. This inevitably leads to NullPointerExceptions at runtime when a project becomes sufficiently complex. Type systems of "low risk" languages prevent such mistakes by offloading this kind of error-prone reasoning from the programmer to the machine.

> Java's type system is so weak that it doesn't even prevent null from inhabiting almost every type.

"So weak"? You do realize that this is basically where every language was less than a decade ago?

Yes, Java's type system "so weak". Just because many other popular languages have similarly weak type systems doesn't make them less weak. Also, as a long-time Haskell user, I can assure you that nullable types were nothing new even several decades ago. Perhaps you have only worked with object-oriented languages, where nullability is typically the default (which is a bad idea).

There are tons of languages with non-nullable types that are much older than that. C++, basically every ML-influenced language, Prolog, Erlang, Tcl.

A decade ago Idris, Agda, Haskell had been around for a time already, there hasn't been that much advance in 10 years. And a decade ago it was also a commonly argued that Java isn't getting a lot in return for its very basic static types, vs simplcity and expressivity that dynamic languages get.

I like Java, but that's weak argument.

We're in 2021, not decade ago.

What language sees wide spread use without at least a decade in gestation? Java, ironically, but cutting edge languages take longer than a decade before making it to the blue collar programmer's floor. I mean the number of people that struggle with even stuff like generics still is amazing and that has been around for 17 years at this point so 10 years is nothing.

And java has excellent static analysis, so if you want to you can prevent every single npe.