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.