Nope. Tooting my own horn here, but the Quasar library on the JVM has both models to the T, performs on-par with Go and blows Erlang/Elixir out of the water in its own game.

> Go also solves the value type issues that cause the JVMs excessive memory usage

True, but not only is that solvable, it is actually being solved on the JVM as we speak, and will be released long before Go will have caught up. OTOH, Go has some serious issues that are unlikely to ever be solved (its reliance on source-code instrumentation and lack of support for dynamic code manipulation; this has been demonstrated to be of great value for many server software systems).

> Code/skills sharing between client and server isn't supported by the JVM either (for web apps that is).

This isn't any worse than any language that isn't JS. On the JVM you have Kotlin, Clojure and Scala, all also compile to JS, and those are just the leading options.

> How do you define "serious"?

Critical software that is required to serve for a decade or more, and whose development costs exceed, say, one man-decade. .NET is pretty much Java's only serious competition there.

I am looking forward for it, but with Brian Goetz speaking about Java 10+ (note the plus) and Oracle not having a programming language culture, I am not sure they will ever happen in the near future.

IBM also doesn't talk any more about Packed Objects and I don't know if anyone is really paying attention to Gil efforts promoting object layout.

Even the Scala guys are now researching into Scala Native.

Of course they do. You're just not looking in the right place.

http://mail.openjdk.java.net/pipermail/panama-spec-experts/

1 to 2 emails per month, for something that might eventually come in Java 10 or later isn't talking about it.

If that is so then kudos to you.

>it is actually being solved on the JVM as we speak

Right, it is being worked on and it will be worked on for many years to come before it gets released I'm afraid.

>This isn't any worse than any language that isn't JS

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.

>Critical software that is required to serve for a decade or more, and whose development costs exceed, say, one man-decade.

Many platforms have that covered. Your arguments in favor of the most widely used platform seem a bit tautological at times. By that standard, Java could never have gotten to the place it is in now.

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.

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.

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?

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.

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.

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.

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.

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).

[1]: http://openjdk.java.net/projects/valhalla/

[2]: http://openjdk.java.net/projects/panama/

Specially with the increasing focus on saving battery and making them as small as possible.

Apparently the GPGPU support is still on for sometime after Java 10.