
Rise and fall of JVM languages - kiyanwang
https://blog.frankel.ch/rise-fall-jvm-languages/#gsc.tab=0
======
norswap
If the language designers keep their heads, Kotlin will slowly eat away at
Java. Java itself is never going away: it's a Fortran or Cobol situation, only
maybe three or four orders of magnitudes bigger.

Xtend never was alive, and it's clear Ceylon has lost at this point, even
though it is arguably better designed than Kotlin. However, they made some bad
syntactic decisions (not shedding enough of the Java verbosity, introducing
new weird keywords), and when you're doing run the mill Java-like programming,
it's just more gratifying to write/read Kotlin code.

Scala's development is somewhat unpredictable, but I think it's fair to say
it's lineage is not going away either. New compilers are being developed by
the original team (Dotty) and by Twitter (reasonable scala) with very
different objectives. Currently, there simply aren't any many contenders in
Scala's niche (very powerful statically typed programming languages with a
pragmatic bend, i.e. not Haskell). C++ could fit the bill but pushes memory
management and Cthulhu on you. The ML family could also fit the bill, but
lacks momentum/hype. However Facebook is spearheading a revival with Reason
ML. Scala's big trump card is the Java library ecosystem.

~~~
pjmlp
Kotlin can never replace Java as long as the JVM is relevant.

This is like trying to replace C on UNIX, C# on .NET, Erlang on BEAM, or
JavaScript on the browser.

~~~
norswap
Kotlin is essentially Java with some sugar sprinkled on top. That's its
strength: the semantics & the concepts are the same.

I also never said Kotlin will replace Java, but that it will gradually grow to
the detriment of Java, which is still here to stay.

~~~
pjmlp
I don't believe Kotlin will get much strong outside Android.

In all these years of alternative languages customers still don't allow us to
use anything other than plain Java.

~~~
swsieber
I have to wonder what the distribution is of people using java is. You seem to
be a freelancer or independent agency for contract. I can easily see a bunch
of big corps moving from Java to Kotlin though. Especially with an in via
android, why not using Kotlin across the board. It will definitely be a
gradual thing, if it will be thing. Kotlin just seems to be a very, very
pragmatic enhanced version of Java.

~~~
pjmlp
Yep, enterprise consulting for Fortune-500, DAX level companies.

------
JBiserkov
No mention of Clojure? In the comments the author says that since it was a
_functional_ JVM language, he never considered it. OK.

~~~
sankyo
He only considers statically typed languages to be worthy. He doesn't spend
much time on Groovy, writing it off as a scripting language. That is my take
on why he left it out.

~~~
Nekorosu
There is a comment from the author that states he hasn't mentioned Clojure
because it's FP language. He doesn't go into details bit it looks like he just
skipped everything that doesn't support class based OOP. Scala has this
feature.

~~~
KirinDave
Clojure supports this though.

And given that removing the FP nature of Scala pretty much hamstrings its
value proposition, I can see why he'd be dismissive of it on those grounds.

~~~
Nekorosu
Clojure supports class based OOP? Never heard of it. Could you give me a link
to the relevant documentation page?

~~~
sooheon
Not really a OOP programmer, but I think the following cover some reasonable
subset of OOP:

[https://clojure.org/reference/multimethods](https://clojure.org/reference/multimethods)

[https://clojure.org/reference/protocols](https://clojure.org/reference/protocols)

~~~
cutler
That's selling Clojure a little short. Clojure has full Java interop via
reify, proxy, gen-class, deftype and definterface.

------
edem
This article is very poorly thought out. First and foremost it talks about the
__fall__ of JVM languages yet it forecasts good things for all of those
languages. The author also failed to check out things like the TIOBE index
where Java is still at the top. Not to mention that Clojure hasn't even been
mentioned which is a __huge__ letdown since Clojure is the only pure
functional language which is native to the JVM.

~~~
hellofunk
I agree. There are many points and oddities in this article that make it a
poor source of information on the topic. Actually, not just a poor source, a
misleading one.

~~~
user5994461
The title is clickbaity, that's all.

------
user5994461
Java, the only language where you can consistently get work by just showing up
to an interview, is not falling at all.

If anything, it will stay here for decades thanks to so many enterprise and
massive projects relying on it.

------
RandyRanderson
I remember reading so many headlines like "email is dead" over the years.
Email is not dead according to every pop-over i see but all those
'replacements' are.

There are very, very few technologies that are 'winners' (pick your own
meaning) in the long run. Choose wisely.

------
krig
> I started developing in Java, late 2001. At that time, Java was really cool.

As someone who was there in 2001, I just have to say: Java was never cool, and
especially not at that time. It was bloated and ugly and slow, the GC was
terrible, applets were simply the worst, the UI toolkits available looked
horrible on every single platform. There were no decent IDEs or editors and
the language was if possible even more verbose and circumspect back then.

~~~
vram22
The Java servlet API and ecosystem was quite cool at least in the early years,
IMO. Very simple and elegant model, and I did some commercial work with Java
servlets. There were 3-rd-party servlet engines (before they started calling
them fancier names like containers after J2EE v1 started :), like
LiteWebServer and JRun (good fun using them), apart from the Sun reference
implementation and and more heavyweight ones like Tomcat which came a bit
later, IIRC. I remember following the Tomcat mailing list for some time, and
there was intense activity on it for a long time. Also used Tomcat and JBoss
later in a few projects. I sometimes mention Jason Hunter's O'Reilly book
"Java Servlet Programming" (1st edition) as one of the best programming books
I've read, both for the content and the quality of the writing and the code
examples.

J2EE v1 was slow and considered by many to be over-engineered (probably why
slow). Used it in one project but didn't like it. I've heard that after v3 or
so (from then called JEE) it became lighter and better. Maybe others can
comment on that. And from some time there have been other options like Spring,
etc. Found Spring rather complex too on an initial look.

What do people on here like using for Java web apps these days (those who do
use it)? Heard of Wicket and Play, I know there must be others.

~~~
Joeri
I've been using play + java 8 for the past two years. Have been quite happy
with it. I did php and node.js before, and I can't say I'm missing anything in
particular from those ecosystems. Build times could be a tad better, and some
aspects could use more documentation, but the code is easy to write and
maintain and the app is blazing fast and easy to deploy. I've gotten the same
positive feedback from other web devs that joined my team. They all like it.

~~~
vram22
Thanks for the info. Might check out Play. Yes, Java performance is fast. I
had read that Sun had put millions of dollars into making it fast [1], hiring
very qualified people to work on the compiler, the JIT engine, etc., over a
period of many years. And the speed difference between early and later Java
versions was perceptible.

[1] Apart from the millions they also put into marketing Java to enterprises.
And that worked, as we know. It became huge in the enterprise and still is.

~~~
cutler
I believe Kotlin code runs close to Java speed which is another reason it
might catch on.

~~~
vram22
Good point. Looking a bit like Kotlin is worth checking out, based on the
comments in this thread, and also that other one some days ago, which was
triggered by Steve Yegge's post about it. The only one drawback I can think of
as of now, is that it is only being developed by one company - JetBrains
(unless it is open source and allows and has contributors, which I have not
checked).

Update: I checked, it is open source:

>In February 2012, JetBrains open sourced the project under the Apache 2
license

from:

[https://en.wikipedia.org/wiki/Kotlin_(programming_language)](https://en.wikipedia.org/wiki/Kotlin_\(programming_language\))

~~~
cutler
These days a new language which isn't open source wouldn't have much of a
chance, I reckon.

~~~
vram22
Question is are you using the term open source strictly as it is meant, i.e.
the source is available, or as some use it, loosely, to mean both open source
and free (as in beer)? [1]

[1] I ask that because all 4 possible combinations of open/closed source and
paid/free software exist. But "open source" is often used loosely by people to
mean both open source and free as in beer, including by well-known tech
journalists or authors who should know better.

I think even closed source languages which are paid, have a chance, just maybe
not very big a one. But that is not a problem as such. Not everyone is aiming
to be a unicorn - more like the opposite. [ This idea of "go big or go home"
(propounded by VC's) is deleterious to the public health (TM:) ] But the
chance is probably big enough for a company or three (for that language) to
live on - provided they get their act right (enough) on all fronts, including
tech and marketing. And even big enough for an ecosystem to build around them.
Such things still exist today, just that they are not so much talked/written
about as much as open source and the latest "hot" trends are. Blame the media
and the cool kids for that.

And I say this as a strong (though not exclusive) proponent, user and somewhat
of a practitioner of open source.

------
0xbear
I wish .net CLR would take its place instead. For one thing, as strange as
that may sound, I trust today's MS more than I trust Oracle. For another, CLR
as of 12 years ago (not to mention now) was already better suited for
programming language development than JVM ever will be, owing to having less
baggage and reified generic types support built in from the start.

------
federicodalmaso
You forget scala-native project: [https://github.com/scala-native/scala-
native](https://github.com/scala-native/scala-native) It seems to have major
traction looking at contributions trend. Together with scala.js it open up the
scala language to three different outputs: native (LLVM), js and JVM. Great
strategy in my opinion.

~~~
izacus
How does it compare to Kotlin native/JS outputs?

~~~
sjrd
In terms of what?

------
Insanity
I'm surprised to see that Groovy slightly beats Kotlin in on that graph. I
really underestimated Groovy popularity, or overestimated Kotlin.

I've yet to work with Kotlin but did like Groovy some years ago. Never used it
professionaly though, only for play-projects.

~~~
chii
groovy is great. It doesn't have much marketing behind it, so it's seems to be
a bit of a quiet achiever. But for dsl makin', groovy is such a good
language.!

~~~
olavgg
We use Groovy in production, working with SQL, Transactions or JSON is much
easier than Java. Meta programming and Traits are other advantages. The
biggest advantage is that it is so similar to Java code, that any Java
developer can pick it up and understand it immediately.

We still love and use Java a lot and they both complement each other very
well.

~~~
vorg
> it is so similar to Java code, that any Java developer can pick it up

Perhaps Java 7, but Apache Groovy doesn't have the lambda syntax from Java 8.
Development on Groovy has stagnated -- someone even contributed a fully
working Antlr-4 based parser to replace their outdated Antlr-2 based one last
year, but it's been sitting in their development repository at Github going
nowhere ever since.

------
kornakiewicz
I'm JVM guy and really wish this platform has something like F# -
"minimalistic" functional language (not like Scala) with static, powerful type
system (not like Clojure).

~~~
berdario
Have you seen Frege and Eta?

[https://github.com/Frege/frege](https://github.com/Frege/frege)

[http://eta-lang.org](http://eta-lang.org)

~~~
jabl
eta looks interesting for Haskell refugees in Java-land..

That being said, any idea why they started from scratch instead of building on
or contributing to frege?

~~~
kuschku
They had ideological differences, Frege focusing on the Haskell standard, Eta
on "whatever GHC does".

~~~
cutler
Pure FP language communities have a lot in common with extreme left movements
where small differences can lead to complete forks. There seems to be an
equivalence between purity and intolerance.

------
olodus
No mention of Clojure? It should defiantly be mentioned as on of the big JVM
languages. Though I get that it maybe isn't what the author was looking for
I'm a bit surprised it was totally overlooked.

------
latchkey
The whole getter/setter argument is trite. Project Lombok has been around for
years and resolves that issue as well as many more.

~~~
lmm
You end up needing more-or-less your whole ecosystem to understand Lombok -
your IDE, debugger, profilers, linters, code coverage tools... it ends up
being just as much effort as switching languages.

~~~
edem
Yep, my thoughts exactly. I tried lombok when I was coding in Java and ended
up dumping it beause it had more issues than it tried to solve.

------
johnflan
> I decided Scala made it too easy to write code unreadable for most
> developers

As a side note, this seems to be the biggest detractor for Scala. Any team
that I have spoken to with Scala experience seem to have had projects that
went too 'Scala/functional'.

~~~
edem
Scala is the Perl of the JVM. :D

~~~
collyw
I have heard that before. I like(d) Perl. Got me tempted to try Scala.

~~~
AzzieElbab
Then don't. I couldn't think of two languages more different in every way.

~~~
edem
They are similar in a way that none of them is readable. At least Perl is
writable...

~~~
AzzieElbab
I find scala infinitely more readable than java. For starters I do not have to
skip pages and pages of boilerplate, unless some genius decided to do 1 to 1
translation of his java code

------
ojosilva
I wonder why Kotlin beat Scala in this virtual programming language traction
game. I don't write code for the JVM anymore, but Kotlin occupies the same
space as Scala.

Was it compilation speed? Corporate support?

~~~
vbezhenar
Scala is much more complex language. Kotlin is more complex, than Java, but
its complexity is just enough to cover major Java pain points.

Scala brings its own huge library with features that I don't need. Billions of
abstract collections, but all I need is HashMap and ArrayList. They generalize
over builders, so `filter` can return some fancy underlying class, but all I
need for filter is to return ArrayList or lazy sequence. Kotlin again hits
sweet point: all it does is extending standard Java library with few utility
methods and it adds lazy sequence type (interface with one method).

Due to Scala huge library it's hard to use on Android with its artificial 65k
method restriction. Kotlin doesn't have this problem.

Last time I checked, Intelij Idea wasn't able to parse even standard Scala
library without errors. May be it's better now, but my experience is that
Kotlin beta plugin was better than Scala plugin. Doesn't relate to language
directly, but complexity of the language is definitely influences tooling:
simplest language Go has awesome tooling.

Compilation time was never an issue for me, but I guess for some projects it
matters.

I don't care about corporate support, but I do care about dogfunding. I didn't
see Hibernate being rewritten with Ceylon. But Jetbrains use their own
language for their tasks, that means that they are unlikely to abandon it.
Google support probably matters a lot for Android developers as well.

That said, Scala is mature language and I don't see it going anywhere soon. It
has very rich set of features, it allows much better abstractions than Kotlin,
it has huge projects, a lot of developers work as Scala developers. But Kotlin
definitely has a momentum.

~~~
bogomipz
>"Kotlin is more complex, than Java, but its complexity is just enough to
cover major Java pain points."

Would you mind elaborating on what those Java pain points are that Kotlin
smoothes over?

Also are people deploying Kotlin on the server side or do you see that being a
thing in the future? For some reason I have this(perhaps incorrect)
association Kotlin only in the context of Android. But maybe that's incorrect?

~~~
vbezhenar
> Would you mind elaborating on what those Java pain points are that Kotlin
> smoothes over?

1\. Explicit semantics for nullable variables. It helps to convey information
whether this function can accept or return null and compiler checks that your
code won't throw NullPointerException. It's not ideal when you're dealing with
Java code, but it works.

2\. Explicit and convenient semantics for mutable and immutable variables. You
can use `final` in Java for variables or parameters, but few people do that,
because code becomes quite verbose. With Kotlin you are using `val` or `var`,
so code doesn't become more verbose.

3\. Almost everything is an expression. Helps to write concise code sometimes
and makes a language more consistent.

4\. Compiler changes type of variable when developer checks for this type. So
you don't have to write nonsense like `if (a instanceof String) f((String)
a)`, instead you write `if (a is String) f(a)`.

5\. Better replacement for `switch` statement. Kotlin's `when` statement has
more features. Not a proper pattern-matching, though.

6\. Default values for function parameters. With Java you have to write lot of
function overloads with slightly different set of parameters and delegate it
to a single function. With Kotlin you're writing one function with optional
parameters.

7\. Named arguments. Sometimes it leads to much more readable code.

8\. Generic parameters can be covariant or contravariant. Basically you can
assign `List<Integer>` to variable of type `List<Number>`. It helps sometimes.

9\. Operator overloading. `a + b` instead of `a.plus(b)`; `m["x"]` instead of
`m.get("x")`. Code looks much more natural, when used appropriately.

10\. Singletons. Kotlin doesn't have static classes, instead it has `object`s,
which are implementation of singleton pattern. They can implement interfaces,
for example.

11\. Proper properties. getter/setters generated automatically, property
access looks like field access, but with all perks the methods have.

12\. No need for artificial utility classes, which are not really a classes,
but just a bunch of static methods. You can either use plain functions at top-
level or enhance existing classes with utility methods. `str.isBlank()`
instead of `StringUtils.isBlank(str)`, for example.

Generally Kotlin is much less verbose than Java, but it's concise enough and
doesn't try to be implicit or magical.

> Also are people deploying Kotlin on the server side or do you see that being
> a thing in the future? For some reason I have this(perhaps incorrect)
> association Kotlin only in the context of Android. But maybe that's
> incorrect?

According to Kotlin developers their user base was roughly 50% : 50% between
server side and Android. I used Kotlin for small server side projects, it
works almost flawlessly with standard Java frameworks like Spring or
Hibernate.

~~~
bogomipz
Thank you for the detailed response. Cheers.

------
hellofunk
I don't know much about Kotlin but whenever I see code samples, it sure looks
like it borrows heavily from Swift.

~~~
dpatriarche
Here's what Chris Lattner said about Kotlin this past June:

"Lattner: Swift and Kotlin evolved at about the same point in time with the
same contemporary languages around them. And so the surface-level syntax does
look very similar. … But if you go one level down below the syntax, the
semantics are quite different. Kotlin is very reference semantics, it’s a thin
layer on top of Java, and so it perpetuates through a lot of the Javaisms in
its model.

"If we had done an analog to that for Objective-C it would be like, everything
is an NSObject and it’s objc_msgSend everywhere, just with parentheses instead
of square brackets. And a lot of people would have been happy with that for
sure, but that wouldn’t have gotten us the functional features, that wouldn’t
have gotten us value semantics, that wouldn’t have gotten us a lot of the
safety things that are happening [in Swift].

"I think that Kotlin is a great language. I really mean that. Kotlin is a
great language, and they’re doing great things. They’re just under a different
set of constraints."

[https://oleb.net/blog/2017/06/chris-lattner-wwdc-swift-
panel...](https://oleb.net/blog/2017/06/chris-lattner-wwdc-swift-panel/)

------
amelius
I'm not a Java guy, but I'm still wondering why nobody every wrote a JVM with
near-zero startup time.

~~~
ztjio
Well I am a Java guy and have two points to make.

First. What are you even talking about?

    
    
      Quiet:test user$ time java Test
      Test
      
      real	0m0.104s
      user	0m0.074s
      sys	0m0.028s
      Quiet:test user$
    

That's on a current MBP 13" top end.

And second: Who cares? What us "Java guys" do with Java, well, it doesn't
matter in the slightest that it takes half a second to start. Because, we
deploy to running processes. "We" power things like Hadoop clusters. The
startup time is meaningless in "our realm" and frankly, I think if you're
wondering about java for something like command line tools, it's just the
wrong tool for the job for many reasons. And if you're looking at GUI apps,
it's still better than Electron :P

So seriously, Hacker News, what is the obsession with this?

~~~
dkersten
The obsession with this is that people would like to be able to use their
favourite JVM language to write CLI tools, consumer-GUI tools or AWS lambda
programs. Sure, you can just say that the JVM is the wrong tool, but that is a
somewhat unsatisfying answer because it still doesn't let me write those
things in clojure/scala or whatever JVM language.

~~~
pjmlp
They can, it is their problem if they keep ignoring the existing AOT
compilers, and there are quite a few.

~~~
kasey_junk
Are there any without an expensive license?

~~~
pjmlp
OpenJDK 9 if on Linux x64, but it is still not yet released.

ExcelsiorJET has a free license for non-commercial uses.

[https://www.excelsiorjet.com/](https://www.excelsiorjet.com/)

[https://www.excelsiorjet.com/#free](https://www.excelsiorjet.com/#free)

RoboVM's fork is another possibility

[https://github.com/MobiVM/robovm](https://github.com/MobiVM/robovm)

------
incan1275
Seriously, using Google search trends isn't the best way to analyze usage or
popularity. GitHub stats (assuming they are publicly available), would be much
better.

~~~
cutler
Surely Indeed.com is the place to look for adoption in paid work?

------
fithisux
He fails to mention Golo.

------
tannhaeuser
TFA mentions Groovy but not JavaScript which could be considered Java's direct
dynamic/scripting variant given JavaScript's origin. In fact, there are two
mainstream implementations of it even (rhino, nashorn), though not upgraded to
ES2015.

~~~
ben336
Java and JavaScript are not directly related. JavaScript added Java to the
name for marketing purposes. JavaScript doesn't run on the JVM like the rest
of these languages

~~~
tannhaeuser
I'm well aware what Java is, given I'm developing for it (and other things)
since 1997 ;)

But my original comment was meant seriously, rather than cheap trolling.
Unlike Groovy, JavaScript has excellent portability and a perspective to
migrate code away from Java/JVM.

