And building Twitter [1], and big-data next-generation databases [2], and android apps, and desktop apps, and big data [3], and as a platform for new languages (Clojure, Scala, Frege), and many more applications.
Really, the JVM can be used for anything that _computers_ can be used for, and it does so in a way that the code is runnable across all major platforms and still maintains a top-5 language performance spot, even beating C/C++ in some specific cases.
Why do you feel that the JVM is limited in its applications as a development platform?
If you say so, I see very few of these in production.
> and big data
Daemon.
> Why do you feel that the JVM is limited in its applications as a development platform?
You can't write cli applications in a JVM language because the start-up time is too slow. Which means you can't compose scripts that call Java apps.
This is not just 1 type of application, it's the most important type of application by far. It's fundamental to how Unix operates. With Java you can't write small applications that do one thing well, you have to write big applications that are going to run for a very long time.
This is useful for things like web servers and daemons, but otherwise it sucks. It's why I can't get excited about JVM languages.
> You can't write cli applications in a JVM language because the start-up time is too slow. Which means you can't compose scripts that call Java apps.
You're right. In the case of small, fast applications designed to be called as part of shell scripts, the JVM does suffer start-up costs. Some testing on my personal machine shows the JVM to be 2x to 8x slower than a comparable Ruby or Python script in startup time. [1] Depending on the script, that startup time may or may not acceptable, and if the script runs for longer than a second, which is entirely possible for anything that goes beyond the local machine, the JVM will get progressively faster.
> This is not just 1 type of application, it's the most important type of application by far.
This needs more explanation. I've used Unix for many years, and I've definitely bought in to its philosophy of small and composable; It's a philosophy that in many ways mirrors functional programming. However, in my opinion, the most important type of application varies considerably by person. For you, the small, single-purpose
applications may be what you use most.
And I agree, if you're programming for the Unix platform, the JVM would not be the best choice. Unix was built on C. A program that builds on that platform is probably a better choice.
But there are many more applications out there, and for any command-line program that operate in a time domain longer than 10 seconds, the JVM startup costs are mostly eliminated. This time-domain is very plausible for a command that operates on medium-scale databases or anything with network connectivity.
It's silly to completely dismiss an entire platform because it is not the absolute best choice for a single domain of programs.
I'm curious: What do you do where the short-lived, composable Unix functions are the most important programs?
I think we simply approach software different. I feel that small, composable applications should be the default, and I nearly always start off this way. I've been involved in projects from writing a specialized version of cp, ETL processes, to developer focused but consumer-facing web applications and the first interface I write to anything I do is as a small cli application that works well with standard unix tools.
When you embrace this philosophy it doesn't particularly matter how good a language's ecosystem is, you have all of unix to interop with. For example, I don't care if a language has a good JSON parsing because jq[1] exists and is probably faster and easier to work with than just about any language's built in tools, even better than JavaScript itself.
With JVM you can't participate in writing software this way. Everything must revolve around the JVM and it's ecosystem.
I'd even say daemons are a stretch. Having multiple JVMs running at once would crush a lot of systems.
The JVM and the Java ecosystem are basically all about long-running backend services. It's funny when you consider Java's roots as a simple language designed to enhance web pages.
Really? Plenty of apps run on the JVM (everything from enterprise apps to games to IDEs etc...). I'm no JVM evangelist (I use Haskell with the GHC), but this is just a false statement.
"Enterprise apps" generally means "enterprise web apps", not standalone, deployed applications.
I've never seen a AAA game written in Java. The non-deterministic GC is a dealbreaker as is the speed and space constraints of eg consoles.
The OP is generally correct: the JVM is a niche technology in a way. The Java ecosystem basically specialises in web apps and backend ESB-type stuff (shuttling data very quickly between heterogeneous applications). Of course, this is a very big, well-paying "niche" so it's not something to be afraid of.
Java doesn't need to have a non-deterministic GC. The Real-Time Specification for Java [1] has resulted in a number of JVM implementations designed for low-power, embedded devices; these implementations use a deterministic GC to provide hard real-time guarantees, and the devices they run on are less powerful than the game consoles from even a couple of generations back.
I would say compiled Scala runs well on the Dalvik VM.
All languages that do not need to generate (or load) class files at runtime should work well on Android. And that is because Dalvik does not run class files.
So then why don't we see more non-Java Android apps in the wild? We can only go off of open source apps, I've looked at quite a bit of those and have ran across only a couple that don't use Java.
