What's really the next big thing after Java?

Recently I stumbled over a discussion at TheServerside about "10 good reasons to look for something better than Java". It starts promising, stating

"Don't get me wrong. During my professional life I have written tons of Java code and of course I think it is a great language still. For sure it has been a great improvement from C++ and Smalltalk. But now even Java is starting to feel the weight of its 15 years."

But then what follows is the usual list of low level language features, like closures or getting rid of checked exceptions. Most of them are highly debatable, with a lot of devil in the details (e.g. closures) and would show productivity gains only after a long time, if at all, when they are widely adopted.

However, the initial statement holds, but the real issue with Java lays far deeper. The thing is that Java was conceived as a language for embedded systems (where it never really took off) but today today most frequently used for multi-user, database-oriented server applications. But the language and its runtime library has almost no support for this class of applications. So you need to pile layer upon layer of frameworks, libraries, application servers etc. in order to build an environment that can implement even the most simple service. Before developers can start with actual coding, they have to make a lot of decisions about architecture, design and implementation of all the components involved.

In a way the situation reminds me on the RISC vs. CISC discussion in processor design, back in the 90s. The idea was that simpler and thus faster processors would be beneficial to overall performance as compilers could not really take advantage of the complex instructions of a more powerful processor. Same with development: The Java ecosystem has everything available for setting up an environment that is optimized for a certain task, but real corporate development teams most of the time cannot take advantage of this as time to market is paramount and time for architecture and design very limited. So usually they stick to what they know best, no matter how much sense it makes for the problem at hand.

That's why I believe that a successor to Java is an language and environment tailored to build server-side applications, with first class support of concepts like transactions, concurrency, distributed computing or clustering. It does not need to be an all-purpose language like Java as we can have a another tailored language, let's say for GUI-based apps. It would require dev teams to code more themselves, instead of looking around to find a library that provides sort of the needed functionality, but in the end lead to a far better understanding of the code.

The most productive language I've ever programmed in was Clipper, a programming language optimized for file-based databases (dBase). It wouldn't hold for today's requirements, but at that time it provided dead-simple ways of putting together an UI (not graphical) for maintaing data in a database, all without an IDE or other supporting tools. And it was efficient - I saw an application with hundreds of clients running against database files stored on a single Novell Netware server.

For a successor for Java, I would say, that is the way to go.