Scala and Clojure, and later Kotlin and others benefited greatly from that niche. The problem for the "better Java" niche was that Java never had to be the best JVM language in order to beat its JVM-based competition in the market. When Java started moving again (Java 8 introduced anonymous functions) and when the release cadence accelerated to every 6 months on 2017, the "Java is stagnant" justification for using other JVM languages lost a lot of traction.
Clojure was never really a "better Java" -- it's a JVM-based Lisp with good Java interop. Scala never leaned too much on the "better Java" niche, and the community is increasingly consolidated around FP. Kotlin still has some "better Java" ambitions, but they also have the Android community at their back. Without Android you would have seen Kotlin trying harder to differentiate itself from Java (EDIT: Google and Kotlin tied the knot in 2017, when Java moved to 6-month release cycle; probably not a coincidence).
Fairly young languages can still see rapid growth -- see Go (1.0 in 2012) and Rust (1.0 in 2015). But you are much less likely to see new languages trying to go head-to-head with Java on the JVM these days.
Most of the popular paradigms (with Java taking the "C++ alike" role) are already serviced effectively by existing langauges.
Of course it does exist and works, so it's mature which is something. But all constants are in memory instead of on disk, no value types, gigantic headers on every object?
C#/.NET is better here.
(I didn't realize but apparently Valhalla is 8 years old now?)
Apparently it has SIMD now, so that's nice.
My point is that the JVM has a huge 3rd party driven ecosystem that's moving at scale. It has very deep backend adoption and has many upcoming projects that will make it even better e.g. project leyden, panama, etc.
It is not without reason that FAANG and Fortune500 companies have many/most of their critical web services running on top the JVM (Apple, Google, Amazon, Alibaba, Twitter, etc).
EDIT:
Some bits and pieces of additional info:
https://ceylon-lang.org/blog/2017/08/21/eclipse-ceylon/
> As you surely know, Red Hat has been the main sponsor of Ceylon over the years, and we're all eternally grateful for this support. It would have been simply impossible to kick-start a project of this scope without the backing of Red Hat. (Full disclosure: we ourselves are employed by Red Hat.)
I had a faulty recollection of this post on the ceylon/dev Gitter https://gitter.im/ceylon/dev?at=5d2765cff5dd14574268bcb3. Funding dried up at Red Hat. Gavin King said that he might try to convince IBM to revive it, but only if he had a clear business case.
> Folks I guess I owe you a bit of a response here, but obviously I have my reasons for not wanting to say too much in public
> As of yesterday I'm an IBM employee which hopefully means that in the medium term there will be more money available for R&D around here, for projects which can make a reasonable case for being worthy of investment in the last couple of years of Red Hat's existence as an independent company, there was essentially no funding available for this kind of project, and Ceylon was a victim of that shortage
> However, obviously, if I'm going to try and convince my fund a new development team for this project, I will have to find a convincing reason to do that, and I will have to think very carefully about what precisely a "next" Ceylon would look like (of course I already have some ideas of mistakes we made, and opportunities that now exist that didn't before, but no clear business case)
> It's probably better if I don't say any more on this topic in this place
Honestly, it was/is a pretty great language.
I think their biggest mistake was picking Eclipse as the IDE. They eventually produced an IntelliJ plugin but it was far too late. The serious JVM dev community had already picked IntelliJ. I don't know anyone who uses Eclipse anymore.
[0] https://projects.eclipse.org/proposals/eclipse-ceylon
I remember Ceylon being touted as a general purpose language that could target the web as well as the backend.
* node.js - 2009
* Ceylon - 2011It was a great language, with awesome features we still don't see in a lot of languages (the way tuples were deeply integrated into the language such that function arguments were treated as tuples, nullable types were just unions Null|T, the advanced module system, type-safe reflection which enabled stuff like type-safe keypaths which someone posted for Rust the other day, were all brilliant included in Ceylon).
However, the execution was not great. There were bugs, there was no killer app/framework for it, the focus was too much on the ideas.
I am quite upset it basically lost completely to Kotlin (and maybe Scala)... I invested a good deal of time learning it and that turned out to be mostly wasted time, except for a few design approaches and ideas that stick with me and can be transferred nicely to less powerful languages.
It's too bad because I personally preferred Ceylon over Kotlin.
Kotlin is a "better java" from a footgun/safety + syntax perspective, and better than Ceylon in most features and ways. So it won that war. And here is another bad idea, from Ceylon's wikipedia:
"Modularity built into the language, based on JBoss modules, interoperable with OSGi[10] and Maven[11]"
Yikes. Three very-obsolete parts of the java ecosystem, and divisive in the ecosystem community at the time of their introduction/use. Not a good strategy.
Groovy was a "better java" with lots of footguns and more-than-one-way and lots of cool features. So it won the scala/whomever war because it was a path for ruby and python people and paradigms. Most JVM evolution has been adopting groovy language features. Not that groovy did them in a revolutionary way, it just had them a lot earlier. But groovy is fading steadily as the JVM adopts its killer features. Groovy is my main programming language on the JVM.
Clojure has the inherent problems of Lisps for popularity, and Scala was possibly the most complicated language every designed. Great for the top 1% of programmers, but oh well for mainstream success.