> Right, it is being worked on and it will be worked on for many years to come before it gets released I'm afraid.
Three or four, most likely. That's not a long time at all.
> Yes, but JavaScript VMs do exist, they are serious competition for the JVM, also, as you say, as a compilation target, which makes it even worse for the JVM. The importance of "runs in the browser" is hard to overstate. And then there is WebAssembly on the horizon.
I agree. If I were to pick the biggest threat to the JVM, it wouldn't be .NET or Go, but the JS ecosystem -- including wasm, which, although low-level at this time and more resembling LLVM, may grow to be a universal high-level VM one day.
> Many platforms have that covered.
I think almost none do.
> By that standard, Java could never have gotten to the place it is in now.
Java (and by that I mean mostly the JVM) were designed after careful analysis of market needs. This kind of analysis is only available to certain players, so it pretty much puts OCaml, Haskell and other academic languages out of the race. This leaves JS, Go, Erlang and .NET. Go seems unwilling to really study the market, so it will achieve success among the novelty seekers, who will then move on to the next thing; Erlang -- which has an amazing, inspiring design -- has no advantage over the JVM, and is at such a huge disadvantage in terms of resources, that the chance of it ever catching up is close to zero. This leaves .NET and JS, both with plenty of resources and a lot of industry involvement, and they are the only candidates that at this time appear to be able to unseat Java.
>Java (and by that I mean mostly the JVM) were designed after careful analysis of market needs. This kind of analysis is only available to certain players
I can't detect even the slightest influence of careful analysis on the rise and fall of technologies. If the creators of Java were planning anything, then it certainly wasn't what actually happened. Java failed completely in all areas it was originally built for (at least until Android, which happened very late in the game and is under threat).
If I had to come up with a formula for success, it would look something like this:
10% novelty-seeking and merit + 10% corporate backing and tenacity of the creators + 10% platform advantage + 70% historical accident.
In Java's history, that 70% historical accident was the web. No one planned for that to happen. All careful planners were taken completely off guard by the web.
Looking at my formula, I would say Swift has a shot at going somewhere. But there are huge wildcards like WebAssembly, the future of Java on Android and of course all the unknown unknowns that are probably going to disrupt all careful analysis including mine.
> But there are huge wildcards like WebAssembly, the future of Java on Android and of course all the unknown unknowns that are probably going to disrupt all careful analysis including mine.
With that I can completely agree. I can't predict when and how the demise of the JVM would come about, but I can see that it's not happening just yet.
I do wonder about one meta-question, though: What effect does the trendy SV tech-marketing-speech has on developer technologies? Ruby was a huge SV hit and now it's ebbing, all without ever leaving a big impact on the software industry at large (sure, it was adopted by the odd "enterprise", but nothing on a grand scale). Now we see something similar (on a smaller scale, I think) with Haskell, Go and Elixir. Will there be a serious impact, or is it a passing SV fashion?
I don't know, but one thing is for sure. All dominant technologies that turned out to have a great impact once started out as something that many thought was a passing fad.
Also, there are some languages that dominate significant niches seemingly forever, like Python as a frontend for math, science and machine learning or R for statistics.
It's very sticky even though I never quite understood why you would want such a huge language barrier between those who implement interesting algorithms in C/C++ and those who use them. I would have thought that there is more overlap between these two groups. I can imagine a similar role for Go in Unix utilities and backend infrastructure.
> All dominant technologies that turned out to have a great impact once started out as something that many thought was a passing fad.
Absolutely, but all fads started out as something many thought was lasting...
> It's very sticky even though I never quite understood why you would want such a huge language barrier between those who implement interesting algorithms in C/C++ and those who use them.
I'm not sure what you mean. My field is distributed/concurrent algorithms, and especially distributed databases, where Java has a significant lead over C/C++ where interesting algorithms are concerned.
I mean things like Theano, Caffe, TensorFlow, torch, mxnet, etc, basically all the leading deep learning frameworks. It's similar in several other math/science related fields. Not that Java doesn't exist in these fields, but it's an also ran.
First of all, that's a very small domain. I can similarly say that C++ is an "also ran" in business server-side applications. Second, I don't think that Watson, Spark and H2O qualify as merely "also ran".
>I can similarly say that C++ is an "also ran" in business server-side applications
Absolutely you can, because it's true. C++ usage has declined dramatically in the last 10 years. It's no longer used as a mainstream language for business applications (something it was never good at).
>Second, I don't think that Watson, Spark and H2O qualify as merely "also ran".
Spark and H2O don't even qualify as also rans in the space I'm talking about. Watson may be an also ran, and significant parts of it are written in C++. I have no inside information, but it's not too difficult to imagine which parts that would be.
It's pretty simple to see what's happening. Just look at Google. Google is a very Java friendly company. They do a lot in Java, just not their core AI stuff. Data shovelling and integration in Java. Core algorithms in C++. That's the pattern.
So yes C++ is used in smaller domains. But these are the most interesting, most innovative and fastest growing domains. Those who really specialize in these areas overwhelmingly use C++.
And it's entirely clear to me why that is the case. I tried to use Java for it (and Go). It doesn't work. I have to be able to load a ton of data into memory without constantly fighting a garbage collector, and I have to be able to specify exactly how that data is laid out in memory.
pjmlp reminded us of IoT. Another up and coming field where Java isn't going to be the first choice. Same with games, video processing, etc. Java is falling back in most new application areas.
Interestingly, web browsers seem to be a pretty good yardstick for many other completely unrelated tasks. Can you write a web browser in it that is up there with the best of them? If the answer is no, then that language is not going to be viable for a lot of other tasks as well.
One reason they do that (that's what leading Java people at Google told me), is that their core libraries need to integrate with all their codebases, some are in Java, some in C++, and some in Python. Another is indeed "intrinsic", but:
> But these are the most interesting, most innovative and fastest growing domains. Those who really specialize in these areas overwhelmingly use C++.
I generally agree (as an algorithms and C++ guy myself, although I now use Java for tricky algorithms, too, because I do concurrent data structures, and those really benefit from a GC), but the languages the algorithms-people use have often been distinct from what the industry at large uses, and that's what we're talking about.
> It doesn't work.
Well, I guess H2O would beg to differ. As to data layout, you're right that's being addressed as we speak.
> Java is falling back in most new application areas.
Those application areas have always existed, Java has never been a leader in those sectors, they're not growing, and Java has still been the most successful language ever. Look, we're not talking Java vs. C++ here. We're talking Java vs. Haskell, Erlang, Go etc.. Those alternatives have even less success than Java in all the areas you mention.
> If the answer is no, then that language is not going to be viable for a lot of other tasks as well.
That is provably the wrong yardstick. Java has never been the best choice for a browser, even while being by far the most used language in the history of computing. We're not counting each type of task equally, but multiplying each task by the number of people involved in doing it.
>That is provably the wrong yardstick. Java has never been the best choice for a browser, even while being by far the most used language in the history of computing.
I should have been clearer about what I think browsers are a good yardstick for. They are a yardstick for choosing a language that is viable if your product can only succeed if it uses computing resources within a very narrow margin of the optimum.
Browsers are an interesting instance of such a product, because they need complex in-memory data structures, they use a ton of memory, they need low level access to hardware and they are soft realtime systems.
But that's by no means a contradiction to Java (and very similar languages) being the most popular language on earth. I see no reason why that should change any time soon.
The only thing that the JVM really lacks compared to C#, Go and Swift is value types. If that's being worked on, I hope it's being worked on fast because it is a big deal.
> They are a yardstick for choosing a language that is viable if your product can only succeed if it uses computing resources within a very narrow margin of the optimum.
Absolutely. HotSpot is indeed the wrong platform for memory constrained environments, as are most GCed runtimes (although JVMs, including versions of HotSpot are used in embedded devices quite a lot, for applications that don't require the best possible use of resources).
I myself have used a real-time version of HotSpot (realtime Java -- RTSJ -- has support for scoped and nested arena-allocated memory) in a hard-realtime, safety-critical missile defense system. It ran on large servers, but current work on RTSJ also targets embedded devices (see https://www.aicas.com/cms/en/rtsj). I don't think this would be a great hit, but there aren't great hits in that market, anyway.
> If that's being worked on, I hope it's being worked on fast because it is a big deal.
Most of the HotSpot team (and not just them) are dedicated to value types as part of Project Valhalla[1], and some resources are directed towards Project Panama[2], that's supposed to be a fast bridge between JVM and native code (essentially replacing JNI with something that's both faster and much easier to write). Java 9 is already feature-complete, but value types are scheduled for Java 10 (maybe panama, too).
Three or four, most likely. That's not a long time at all.
> Yes, but JavaScript VMs do exist, they are serious competition for the JVM, also, as you say, as a compilation target, which makes it even worse for the JVM. The importance of "runs in the browser" is hard to overstate. And then there is WebAssembly on the horizon.
I agree. If I were to pick the biggest threat to the JVM, it wouldn't be .NET or Go, but the JS ecosystem -- including wasm, which, although low-level at this time and more resembling LLVM, may grow to be a universal high-level VM one day.
> Many platforms have that covered.
I think almost none do.
> By that standard, Java could never have gotten to the place it is in now.
Java (and by that I mean mostly the JVM) were designed after careful analysis of market needs. This kind of analysis is only available to certain players, so it pretty much puts OCaml, Haskell and other academic languages out of the race. This leaves JS, Go, Erlang and .NET. Go seems unwilling to really study the market, so it will achieve success among the novelty seekers, who will then move on to the next thing; Erlang -- which has an amazing, inspiring design -- has no advantage over the JVM, and is at such a huge disadvantage in terms of resources, that the chance of it ever catching up is close to zero. This leaves .NET and JS, both with plenty of resources and a lot of industry involvement, and they are the only candidates that at this time appear to be able to unseat Java.