[bdamm]

Languages like Matlab are best suited for expressing calculus. Why are you choosing a poor tool for the job?

Most Java programmers don't care about expressing calculus. They care about expressing interactions between web services, sql, and applying rules as the data flows through their modules. Or between user interface elements and service requests. It's all about moving data around, working on that data when you've got it, and triggering actions.

[fleitz]

The problems of pushing bits from one server to another aren't that complicated and the pomp and circumstance of java gets in the way of actually accomplishing those things.

As you point out when you have a reasonably complicated problem like applying functions java fails miserably and other languages are a much better choice.

[cgh]

No offence, but it's clear you have no idea about the domains in which server-side Java is typically used. Very large enterprises have all kinds of weirdness and the Java ecosystem has a bunch of libraries found in no other language ecosystem that make things manageable. Java-the-language is sadly verbose and tedious but that's not why people choose it.

So server-side Java lives in a niche and I would never suggest it for, say, anything client-side or basic web apps.

[tracker1]

I'd say that NodeJS or Ruby would be decent alternatives depending on your need. npm and gem are really nice in this space and cover just about any need you might have without weighing your system down in pomp and circumstance.

The runtimes aren't that much slower, and for I/O bound tasks, odds are Node is going to run just as fast with less application complexity.

[bdamm]

Actually, part of the problem is the academic experience of believing that applying functions is hard and pushing bits is simple. It deceives delusional academics like yourself into believing it's just a matter of doing the work and not really a real computation problem at all.

No, in the real world, it's exactly the opposite. Nobody cares about writing a function because generally that's the simple part. Do it however you want. Deploying the system to take inputs and feed outputs, now that's the hard part. Where do those inputs come from? In what form? Are there security requirements to gather or push data? Do you store-and-forward or don't you? What protocol? Stateful or not stateful? Transactional or not transactional? The problems involved in "move these bits in this format on this machine to those bits in that form on that machine over there" are in fact so complex that you can't even prove it to be an NP-complete problem because the problem itself transcends algorithmic analysis. It is much more a social problem than a technical problem, but the social problem is so massive that any simple-minded technical approach will fail to address the scope of the issue and in every case I've ever seen, simply makes the problem worse.