
Kotlin becomes second most popular language on the JVM - fulafel
https://snyk.io/blog/kotlin-overtakes-scala-and-clojure-to-become-the-2nd-most-popular-language-on-the-jvm/
======
gibolt
I started using Kotlin daily about 8 months ago.

Recently had to go back to an older Android codebase, and immediately decided
I had to start converting.

The amount of boilerplate is unbelievable. I'm able to cut the number of lines
by half while increasing readability. Type/null safety is a huge added bonus

P.S. Kotlin extensions are the best

~~~
tommyage
About one and a half year ago we also decided to give kotlin a shot. After a
few months my opinion was similiar to yours. Extension-functions, yeah!

Anyway, nowadays you wouldn't see me making the same statements anymore.

My first issue appeared when I was maintaining an Android app written in Java.
I needed an library for some functionality. The only maintained ones were
kotlin-libs. But interoperability, right? I didn't hesitated to include it.
There is no way to use or extend functionality with typealiases in your java
code.

IntelliJ can compile Kotlin into Java and it is easily accessible. But there
is no adb debugger for kotlin.

Null Safety is just overhead imho. I know when it is appropriate or neccessary
to check for null, otherwise i can get rid of it. And its more easily grep-
pable the Java way.

Writing Kotlin is not so fluent as one would guess, the tooling only fools
you, that it is. You can easily make use of actions like typing pfi (extends
to public final int) for java aswell. But when your property changes from
nullsafe to nullable, you need to rewrtiging eeevverything.

Additionally, i do not like the implicit type on member property declarations
used by almost anybody. The benefit of typing less boilerplate becomes
annoying when reading sources outside your ide.

Boilerplate in my opinion is code i need to write by myself. When it is
generated by any IDE, i do not bother about it. We are so familiar with Java
that we can abstract this boilerplate when reading sources.

Spelling Kotlin to somebody via telephone is also strange for me.

I stopped promoting Kotlin as a Java killer. Code style is too different
between different developers.

And why are we creating the same libraries once again?

~~~
nemetroid
> But when your property changes from nullsafe to nullable, you need to
> rewrtiging eeevverything.

Isn't the fact that you have to be explicit about null the main feature of
explicit null safety?

~~~
tommyage
Yes, it is, but the domain req. can change, requiring to handling an nullable
result

~~~
thu2111
Isn't that the one big situation where null safety _really_ shines? Something
that used to be required is now optional, so, you need to visit all the use
sites to figure out what a sensible behaviour is when the data isn't there.

Without null safety that could be quite tricky, especially when combined with
type inference. The value could be stored and used only later, for instance.
The compiler flagging where those fields are used without a null check is
convenient, it tells you exactly where to insert new code to handle the
missing data.

~~~
tommyage
Thank you, I shall be more precise when giving any comment. Honestly, I have
not considered the advantages from null-safetyness (rated anything..) properly
before posting. I just wanted to rant about kotlin, since i hear too many
prayers about it and my gud (stomach) tells me different. I am not able to put
it into words, yet. I really appreciate your hint.

Anyway, you are absolutely right and I am glad @jach posted an link (above)
regarding my intuition (@shoutout). When I learned programming (with Java, 3
yrs. ago) my mentor pointed out that i included too null-checks, even though i
was familiar with the entire code base. Just after reading a post on this
platform I realized his real intention: Sometimes (most often!) we needlessy
check for null. Since then, forcing me to check anytime for null feels wrong
and kotlin is forcing me to do so.

Eventually I just wanted to mention downsizes which comes into my way when
using kotlin daily..

Thankfully..!

~~~
thu2111
You're welcome!

------
dcolkitt
Let me ask a question as someone with pretty minimal Java experience. If
someone was starting a greenfield JVM project today, is there really any
compelling reason _not_ to choose Kotlin over Java?

Because the impression I get is that Kotlin is a strict improvement along
every dimension. But as an outsider, I'm not sure if I"m just being blinded by
hype.

~~~
BossingAround
There's also the question of long-term sustainability. Groovy was very cool
and popular in 2010. Ten years later, Groovy is still in the production
codebase while the language is essentially dead.

I personally wouldn't go for anything but Java (on JVM, that is) for anything
that isn't a pet project.

~~~
msclrhd
Note that with Kotlin, JetBrains created it initially for working on their
IntelliJ IDE and are porting their Java codebase to use Kotlin. So that is a
good indicator of long-term sustainability.

~~~
pjmlp
Nowadays there are trying to just get Kotlin anywhere and it remains to be
seen how Valhalla and Panama will be usable from Kotlin.

~~~
thu2111
Panama would not seem to pose any problems as it's all code generation with
MethodHandles/VarHandles. That should be directly callable from Kotlin.

As for Valhalla, it remains to be seen how it's usable from Java, let alone
anything else. But Kotlin already has a form of value type (inline classes) so
perhaps it'll be an extension of that.

~~~
pjmlp
Kotlin inline classes are heap allocated, they are just syntax sugar for
regular classes.

One cannot just change their semantics after the fact.

~~~
Nullabillity
Kotlin's inline classes (and Scala's AnyVal classes) are syntax sugar for
static methods. The object itself is erased completely whenever possible (just
like primitive values).

~~~
pjmlp
Which is not the same as the semantic meaning of doing stack allocations or
being stored in registers.

~~~
Nullabillity
The following:

    
    
        case class Foo(x: Int) extends AnyVal {
            def square: Int = x * x
        }
        val bar: Foo = Foo(5)
        println(bar.square) // => 25
    

Compiles down to (the moral equivalent of)

    
    
        object Foo {
            def square(x: Int): Int = x * x
        }
        val bar: Int = 5
        println(Foo.square(bar)) // => 25
    

If the inner value (x, in this case) can be stack-allocated or stored in
registers then `Foo(x): Foo` will as well. `Foo(x): Bar` (where Bar is a
supertype of Foo) will be autoboxed, but that also applies to primitive types
(`5: Any` becomes a java.lang.Integer in memory).

~~~
pjmlp
Neither of those represent the same semantics of:

    
    
        inline class { ... ]
    

Which is guaranteed to be always stack-allocated or stored in registers, again
you cannot retrofit semantics, specially when passing those classes to binary
libraries.

~~~
Nullabillity
You're correct that the Scala version isn't ABI-compatible. But Scala doesn't
care about ABI between minor releases anyway, so that probably wouldn't stop
them from changing it to align with Java.

There is also precedence for this, Scala 2.12 changed the encoding of lambdas
from anonymous classes to Java 8's invokedynamic.

------
insulanian
I was surprised to see that Clojure scored better than Scala. Is Scala loosing
its appeal? Did Dotty scare people away, because it smells like Python 2 vs 3?

~~~
dehrmann
My feeling is that between sbt being painfully slow and Java 8 getting
lambdas, people lost interest in Scala.

~~~
ofrzeta
Maybe. I just wanted to point out that there's Mill as a build tool for Scala:
[https://github.com/lihaoyi/mill](https://github.com/lihaoyi/mill)

(by the Scala.js maintainer Li Haoyi)

~~~
saityi
The last time I gave Mill a shot, I couldn't find a way to authenticate into
private artifactory repositories, which made it kind of a nonstarter. Do you
know if this has since been added?

------
thowfaraway
Solid tooling can really boost a language. Clojure advocates should
internalize that.

~~~
Barrin92
emacs and cider are rock-solid tools for Clojure, as are equivalent plugins
for other lisps. It's not a very beginner-friendly tool, but I'm pretty
convinced it really is the best environment for lisp development there is.

I'm not saying that having more mainstream tooling wouldn't be good, but
people should not be discouraged from Clojure or Lisp development because of
an apparent lack of tooling.

~~~
thowfaraway
Telling someone new to a language to start with emacs & cider is a disaster.
They are rock solid amazing tools for 2% of programmers. I like emacs, but it
is harder to learn than Clojure, and trying to teach someone both at the same
time is tough. Plus there is no real community unity in editor choice, so you
have the community split over emacs, Cursive, VS Code/Calva, Atom. Plus a
bunch of dead ends like Light Table or Nightcode.

~~~
puredanger
You say that like having 4 or 5 solid editors for Clojure is bad because no
unity. To me, it seems great because there are a wealth of choices for people
that like different things and many of them are excellent, well above the bar
for being a productive developer.

~~~
thowfaraway
It is probably net positive for advanced users who have niche needs that the
different editors address, but I'm saying it is bad for beginners/learners.
More specifically, I'm saying emacs/cider is bad for beginners/learners, and
the more traditional IDE options aren't so solid.

------
emmanueloga_
Props to [https://ceylon-lang.org/](https://ceylon-lang.org/) for a good
effort. It doesn't seem to be on the race anymore, but at the time it looked
like a super interesting contender.

~~~
imtringued
It was a good example of how to build a language in 4 years but the JVM
language space is already filled to the brim. The only way to stand out is by
having a large vendor bless it (Kotlin on Android).

~~~
thu2111
I'm not sure that's the whole story. Kotlin was blessed on Android because it
was growing like a weed, developers didn't need Google's permission to use it
and weren't asking for it. The Android team went with the flow (smartly).

I evaluated Ceylon vs Kotlin in 2015, back when Kotlin wasn't even close to a
1.0 release and neither had any adoption. They're very similar in a lot of
ways and so the choice came down to a lot of small things added up rather than
any one big thing. I chose Kotlin for a lot of reasons, but a few (in no
particular order) were:

1\. It had a more convenient syntax. The Ceylon designer felt that
autocomplete meant verbose syntax didn't matter but it does. "variable Integer
foo = 10" isn't just a typing issue but also a reading issue. "var foo = 10"
is better.

2\. Ceylon deviated more from the JVM ecosystem than Kotlin, in particular, it
invented its own collections like Scala, but which didn't appear to be much
different to regular Java collections. This means idiomatic Ceylon would
obviously _be_ a Ceylon library to users and not a Java library. Kotlin uses
standard Java collections but enhanced via extension methods. It also provides
a bunch of knobs to make the output classes seem like idiomatic Java classes
in the few places that doesn't happen automatically, so you can reasonably use
it for libraries. This makes a huge difference to Java interop. Kotlin is
really the only JVM language that takes Java interop seriously: the rest all
treat it as a price of admission to use the JVM at all and minimise their
effort on it.

3\. Ceylon was mostly tooled for Eclipse which, in my view, is an inferior IDE
to IntelliJ. The tooling was itself not as good as even the pre-1.0 Kotlin
plugin.

4\. Ceylon had invested heavily in a complicated module and type system, which
was the primary set of things they emphasised. These sorts of features have a
relatively poor track record of delivering value; slightly-stronger-than-Java
seems to be about the sweet spot at the moment. Much stronger than that and
you end up in Haskell. Kotlin went in for more type inference and more usable
generics (convenience), Ceylon

5\. Ceylon seemed much riskier to me (correctly). Nothing used it. It was
clearly the project of one guy at Red Hat who'd had a previous successful
project (Hibernate), but Red Hat weren't talking about it or using it in any
way. On the other hand JetBrains had a large team assigned to Kotlin and were
explicit that they were creating it to use in IntelliJ itself. The existence
of a Java to Kotlin converter tool showed that they were completely serious
about this, as J2K was a lot of work to build and would only be useful in a
truly serious assault on existing Java codebases. Ceylon seemed far more
interested in fancy type systems than the practical details of adoption.

6\. Ceylon had some weird gotchas and interop glitches that weren't normal for
Java-like languages, like a sensitivity to the case of the first letter of
identifiers (I know Go does this too) and difficulty handling Java arrays.
There are named constructors (cool) which don't compile to static methods as
is idiomatic for Java but some weird Ceylon specific notation (boo). This sort
of thing showed it wasn't trying to be "just a better Java" which is what I
was in the market for.

~~~
emmanueloga_
Wow, thanks for the analysis! I think it was very astute to pay attention to
how Red Hat was supporting (or not) the language, it never occurred to me to
look at the project from that POV, a really useful one.

I think the language is quirky in a lot of ways with the verbose syntax being
one of them. I liked some aspects of the type system that made it look close
to an ML flavor, although the language had heavy OOP syntax. In this way I
thought it was similar to Scala.

There are a few nice write ups from the author on the process of coming up
with the syntax. The one talking about constructors is a good example [1].

1: [https://ceylon-lang.org/blog/2015/06/21/constructors/](https://ceylon-
lang.org/blog/2015/06/21/constructors/)

------
dlbucci
Having recently started writing a bunch of Kotlin to replace Java, I'm happy
to hear this! Type inferencing, data classes, and non-nullability make it so
easy to use and have helped me catch bugs, too! I don't enjoy it as much as
TypeScript yet, but it's a close second :)

------
pjmlp
No wonder, having an whole OS as godfather, with on maintenance Java language
support.

However don't party too much, all of them counted together are still a
minority versus Java on JVM, as clearly shown.

------
dehrmann
I haven't used Kotlin, but when I read through some examples and guides, it
felt like Java with all the messy legacy cleaned up, but it was still
familiar.

------
jvican
What is the methodology behind these results? If it is what I read in the
introduction, judging Kotlin to be more widely used than Scala based on a poll
is deceiving and IMO loses any weight this report might carry.

------
_Codemonkeyism
We build and scaled a startup based on Scala code and successfully sold it, so
- with all the Scala problems [0] in mind - Scala will always have a place in
my heart. Using IntelliJ since a decade+ I wish those guys the very best with
Kotlin.

[0] Binary incompatibilities, very very slow compilation speed, atrocious
build tool

------
_bxg1
Seems like Kotlin is basically "Java: The Do-over", right? Unlike Clojure and
Scala, it aims for the same use-cases, a similar multi-paradigm balance, etc
to Java, just with an extra 15 years of language design hindsight.

------
bozoUser
My first impression is that Kotlin is being mostly being used by the android
community.

Is anyone using Kotlin to write services, what are your experiences with that
?

------
LessDmesg
Kotlin is Java done right. It's what Java would have been from the start, if
only original Java designers weren't C++ copycats in a rush.

~~~
iainmerrick
Every single popular language was rushed, and every single one borrowed many
ideas from elsewhere.

~~~
LessDmesg
Yes, so it's great to see at least some of them get to the 1.0 version
eventually (and I mean Kotlin = Java 1.0). Now if only we could get people off
the pre-release versions of Java (which for some reason are named "Java 11",
"Java 12" instead of "Java 0.9.1", "Java 0.9.2" as they should) and on to the
real deal!

Seriously, I have great hopes for Kotlin. It corrects some Java's most
egregious sophomore mistakes, it doesn't try (and fail) to be Haskell like
Scala did, it's accessible AND has a major company behind it. Kotlin is surely
something I wish I could use at work.

------
runT1ME
I do think Kotlin is a 'better java' while Scala fails to satisfy that niche.
However, I wonder if we'll actually see some big Open Source
projects/platforms released that are written in Kotlin. For Scala you have
Kafka, Spark and Flink which are widely deployed in the enterprise. Will
Kotlin have a marquee infrastructure project to tout soon?

------
fulafel
turk73's comment
([https://news.ycombinator.com/item?id=22258252](https://news.ycombinator.com/item?id=22258252))
can't be replied to for some reason so replying at top level:

I agree that switching between languages can kind of drain you of a good touch
to your working language. I think this is a real downside about all the other
langugaes that a dev today has to deal with too (Ansible, bash,
CloudFormation, CSS, etc. I like Clojure because you can use the same good
language on the frontend and backend.

> 3) Recruitment for Kotlin devs is impossible. You have to train people and
> companies won't do that, so there's no pool of talent ready to go.

Is this really a common problem in the corporate world? In my experience
people are to quick to pick up at least dynamic languages. I guess it's
possible that Clojure is easier in this respect, or maybe Clojure jobs just
attract people with a more exploratory attitude.

------
gazarullz
I wonder how long is it gonna be until Kotlin will have the same fate as
Groovy and Scala.

Don't get me wrong, I appreciate both Groovy, Scala as well as Kotlin. History
has shown that Java has always managed to move forward and superseed the
former.

------
jakear
First is Java, 87%. Does anyone here know how JVM ecosystem is governed? Do
the needs of Java dominate or can smaller languages get change requests in
reasonably easily too?

~~~
dtech
Java dominates, also because that's the main source of engineering capacity.

There are some notable exceptions though. E.g. invokedynamic from JVM 7 was
only really used for Java starting at 8 (with the introduction of lambdas),
and was partially introduced to better support dynamically typed languages
like Ruby on the JVM.

The languages do benefit from JVM improvements. Scala 2.12 had a significant
speed-up due to native lamba support from JVM 8, and if project valhalla ever
lands you can bet all JVM languages will be happy to use it.

~~~
pjmlp
Guest languages cannot make use of Valhalla/Panama without having plaform
specific extensions.

Basically they will end up with some form of conditional compilation or
performance loss emulating those features on other platforms (if at all
possible).

------
hyperpallium
Yet still can't compile kotlin on android.

~~~
sgt
What would be the use case of compiling Kotlin on Android?

~~~
hyperpallium
Developing on a phone or tablet.

~~~
sgt
But I mean... that must be a terrible developer experience. Why even bother?

------
_pmf_
Well deserved. No academic high browing, no armchair hammocking, just
accessible pragmatism.

~~~
6gvONxR4sf7o
What does armchair hammocking mean? I've never heard the phrase before.

~~~
_pmf_
I'm referring to the very entertaining, but a bit truism-heavy and patronizing
presentations of Clojure's Rich Hickey, for example "Hammock driven
development":
[https://www.youtube.com/watch?v=f84n5oFoZBc](https://www.youtube.com/watch?v=f84n5oFoZBc)

I like Rich Hickey's philosophy and personal style, but Clojure just falls
short in every aspect as an implementation thereof, in my opinion.

For example, it switched from heavily promoting STM as a concurrency primitive
to "app state in atom" to new async/channels.

~~~
capableweb
I don't think you can call clojure.async as something that was made for
switching anything, replacing it. Both ways exist and are being promoted for
their use cases. I think Clojure is one of the few languages where things have
been very stable for a good while. Maybe it's being developed slower than
other languages, but using Clojure is nice because of the trust you have of it
remaining the same. Everything else is basically libraries on top of the
language itself.

------
jjtheblunt
genuine question: why Kotlin when Scala already exist[s,ed] ?

