
Rise of Kotlin: A Programming Language for the Next Generation - mikece
https://hackernoon.com/rise-of-kotlin-the-programming-language-for-the-next-generation-27beeb529204
======
pdpi
I've been doing Kotlin on the backend for a while now, and I can't recommend
it enough. One of the things that I really enjoy about the language is that it
is _not_ a clever language. It's not trying to revolutionise PL theory, it
just wants to get out of your way and let you get on with it. This shows up as
the language being mostly worried about bringing well-understood modern
conveniences into the Java world (interface delegation, property delegation,
data classes, generic variance, type inference, etc).

On top of that "modernised Java" base, the language then adds only a small set
of clever new features (mostly inline functions and receiver lambdas), and it
leverages the hell out of those few features to produce a lot of value — e.g.
there is no try-with-resource in Kotlin as a language construct. It's
implemented as an inline receiver function that takes a receiver lambda as an
argument.

~~~
Waterluvian
When I think about language that gets out of my way for the backend I think
Python. I really need to find time to dig deep into a language like kotlin to
confirm or dispel my assumption that nothing else comes close to python for
getting out of my way and letting me focus on the problem not the code.

~~~
pdpi
Kotlin is very much meant to operate at the same level of abstraction as Java,
which is a fair bit lower-level than Python. If you don't need to work at that
lower abstraction level, Python will still feel a bit nicer. Kotlin definitely
closes some of that gap, though.

~~~
nine_k
Kotlin gives you enough metaprogramming and syntax sugar to feel a rung above
Java. You can pack a lot into a short line (list / map literals, compact map /
fold / iteration, elvis operator), so it feels to me much closer to Python
than Java 8 ever did.

------
valw
I have nothing against Kotlin, but we should be much more ambitious for the
Next Generation of programmers. There's so much more progress to be made in
(mainstream) programming languages than the tiny step from Java to Kotlin.

As it has always been in the history of programming, what it takes for this
potential to come true is for the current generation of programmers to retire,
leaving room for fresh paradigms.

Imagine if all the industry got one generation after Assembly language was
"hey, we've made the instruction codes shorter and an IDE that can navigate to
line numbers".

~~~
vbezhenar
What features do you miss in Kotlin so much?

~~~
clhodapp
Not the person you are replying to but:

* Typeclasses (over higher kinded types)

* Extensible typeclass instance derivation

* Comprehensions on par with SQL in expressiveness

~~~
nine_k
Typeclasses can be introduced; there's a PR doing that in a reasonable manner:
[https://github.com/Kotlin/KEEP/pull/87](https://github.com/Kotlin/KEEP/pull/87)
It's not shot down.

Instance derivation is likely not impossible when typeclasses support is
there. I wonder how expensive it could be, though. Making them also usable
from Java (e.g. Comparable) would likely be problematic sometimes due to
Java's inconsistencies.

Can receiver lambdas (the "DSL" feature) be used to produce something
comparable? For something comparable to LINQ, though (same expression
targeting e.g. an object graph _and_ an SQL database), compiler support would
likely be needed.

------
KirinDave
It's pretty sad that F# is sitting on the sidelines wondering what it did
wrong to not get these accolades. I guess, "Being unable to enter a mobile
ecosystem that's being held on a very old language runtime," is perhaps not
the most desirable outcome for Android but dang if it hasn't worked out well
for Kotlin's press.

People are going TO Kotlin as opposed to the usually
Ocaml/F#/Haskell/Idris/Agda world of the community trying to bring people in.

~~~
systems
from where do you get that F# is sitting on the sidelines?

i see more books and open source projects for F# than kotlin, which for a
while made me skeptical about the truth of kotlin popularity

~~~
KirinDave
I talk to a lot of Android folks. Most have already made the switch, and
consider the growth of the language "explosive". That Google is opting in
there only makes it better.

F# has been around a long time and while it's experiencing modest growth and I
think it has a positive track, I've certainly never seen it hyped and on the
tip of every tongue the way Kotlin now is within the Android space.

~~~
AnimalMuppet
I think it is completely unrealistic to expect F# to gain traction in Android.
Google would never support it, and I don't think the platform is open enough
for others to make it happen.

------
cwyers
A lot of this seems to be driven by Android developers who are locked into an
older version of the JVM because of decisions Google has made. In other words,
Kotlin is taking improvements from languages that target other environments
(the CLR, native compilation or even newer versions of the JVM) and giving
them to programmers who are stuck on a version of the JVM that isn't seeing
any progress.

~~~
pjmlp
Yes, Google has radio silence on adopting anything beyond Java 8.

And even for Java 8 you need a latest Oreo device, because not everything can
be desugared into Java 6.

There is also the issue that going forward Java 9+ libraries won't be possible
in Android.

So the only way forward appears to be indeed Kotlin and Kotlin specific
libraries.

~~~
ajoy39
Probably has something to do with that ongoing lawsuit with oracle

~~~
pjmlp
Easily avoidable if Google had not screw Sun in first place, and if they
bothered to buy it afterwards when Sun went bankrupt.

Apparently they thought they could get away with it.

And there are still lots of jars on Maven central that are unusable on Android
Oreo.

Because even after switching to OpenJDK, they cherry pick APIs from there and
ART does not support all JVM bytecode features.

------
bsaul
So Google has golang, which seems to be great for some kinds of server-side
development. Then it backs kotlin which is great for android development, and
also embraced by large server-side framework such as Spring. Then it has Dart
for flutter and cross-platform mobile development.

We're now at the point where google has 3 very good programming language, each
successful in their initial environment, but are necesseraly going to try to
reach out to the other's languages territory. Flutter / Fuchsia is supposed to
replace Android, Dart is very interesting for server-side development, and
Kotlin aims at "worldwide domination" since it's based on the JVM.

That's exciting, but also very confusing if you want to find the good
environment to specialize in.

------
dgritsko
Steve Yegge had an entertaining and informative post last summer describing
his own experience with Kotlin and his thoughts on what makes it a compelling
language. It's a great read: [https://steve-yegge.blogspot.com/2017/05/why-
kotlin-is-bette...](https://steve-yegge.blogspot.com/2017/05/why-kotlin-is-
better-than-whatever-dumb.html)

------
newcrobuzon
I would wonder: is there any person with (enough of) experience with both
Clojure and Kotlin to say how these two compare together as Java alternatives?
Couple of years ago I was looking for "Java.next" and back then I chose
Clojure. Needless to say I have been sooo happy with the language... Now for
past year or so I have heard so much praise on Kotlin - it always came from
Java devs and it seems like a great language with great support from IntelliJ
and I am very enticed (but sadly have not enough time to play with it). So I'd
wonder how this language is perceived by fellow people from Clojure
community...

~~~
edem
I have worked with both professionally for 3+ years so here are my 2 cents:

Kotlin is like buying a Volkswagen Passat after having a Golf. Clojure is like
buying a BMW. The former is a reliable and solid workhorse, with a bit of
charm. The latter is a powerhouse with flaws.

If I only evaluate them based on their merits on paper Clojure definitely
comes out on the top. The problem is that there are countless other factors.
While Kotlin is just a Turbo Java, Clojure has a completely new paradigm.

With Kotlin I get an IDE which is superb, I get all the tools Java has. The
interop is amazing.

With Clojure the only IDE which worked for me was Emacs but even that is a bit
flawed. When I used Clojure I always had this mental overhead of fiddling with
Emacs, the concepts of Clojure which are not inherent in LISP and so on.

In the end, I dumped Clojure for Kotlin because I don't see a future for
Clojure. I can't get contributors for my open source projects for Clojure but
with Kotlin they just come and do some pull requests. I can't get Clojure
programmers in my home country because there are like 40 of them in the whole
country and most importantly I can't convert Java programmers to Clojure
programmers.

Kotlin, on the other hand, is not a big mental leap from Java and a lot of
Java developers are excited about it. When I want to hire someone to work on a
Kotlin project I can just bring in Java devs who are interested because they
get up to speed in a matter of days.

The other problem with Clojure is that it has so much baggage over the basic
LISP concept. It is not simple enough to pick up for most programmers with 0
FP experience. If I want a LISP I'd rather go for Racket which is actually
simple.

~~~
yogthos
I've been working with Clojure for about 8 years professionally now, and I
haven't touched Emacs in all that time. I started with CCW for Eclipse, and
later moved to Cursive with IntelliJ. I find the IDE experience for Clojure is
quite reasonable now. You get a lot of what you'd expect in terms IDE support
such as automatically requiring namespaces on usage, finding usages for
symbols, auto-refactoring, and so on.

In terms of hiring developers my team hasn't had a problem with that either.
We've only hired a single person who knew Clojure ahead of time, and we
trained the rest of the hires on it on the job. Our experience is that it
takes about a couple of weeks for somebody to start writing useful code with
guidance. We start by doing a bit of pairing, and we do code reviews for pull
requests where we help make sure new hires are writing idiomatic code. When
you have at least one experienced Clojure dev on the team already, onboarding
tends to be pretty smooth.

One huge benefit we found posting for Clojure is that we get completely
different set of applicants than when we posted for Java. There are many
excellent Java devs out there, however finding them is like looking for a
needle in a haystack and you're competing with many other companies for them.

Meanwhile, most people applying for Clojure jobs tend to have genuine interest
in learning something new, and they're very enthusiastic about it. We get a
smaller pool of applicants, but on the other hands most of the people applying
are actually worth considering.

~~~
edem
Where do you live? SF I presume?

~~~
yogthos
I work at a hospital in Toronto, Canada.

~~~
edem
Yep, Toronto is a nice place, but in Budapest, Hungary Clojure programmers are
basically non-existent. What you are saying might fit Canada, or the USA, but
not every other part of the world.

~~~
yogthos
My main point was that we don't hire Clojure programmers on my team. We hire
programmers who are willing to learn new things on the job, and one of these
things happens to be Clojure. I see this is as a helpful filter because if
somebody isn't willing to learn a new language, chances aren't very flexible
as a developer in general. The nature of our industry is that it's constantly
evolving, and you have to be adaptable to keep up.

------
DrBazza
> One takeaway is that Kotlin is an exciting language, and one that makes
> developers happy.

Context? Probably "makes (Java) developers happy" due to dramatically reduced
verbosity. But you get that in most, if not all other languages too. It's not
called the Kingdom of Nouns for nothing.

~~~
KirinDave
It makes Android developers very, very happy because it brings features and
fixes issues they have. They're stuck on a very old version of the Java spec,
remember. They don't really have great options for other languages because of
the huge amount of specialized executable optimization and processing required
to ship on Android.

It'd be awesome if we could see a similar uptake in Eta or something like
that. But it's unlikely, as making Eta equally efficient on Android will be a
full on PhD thesis of work on top of a mountain of integration work JB
finances to get the tooling perfect.

------
usrusr
The article talks much about how Kotlin is picked up disproportionally by
younger developers. In addition to the obvious Android connection, this might
also be because older Java developers are not only more content with Java
(self selection: those not locked into Android development would have left
Java for good a long before Kotlin came along if they wanted to), but also
because many of those open for new languages but still tied to the JVM have
already been spoiled and/or burnt by Scala.

Spoiled _and_ burnt? I see a lot of potential overlap where one would have
learnt enough Scala to perceive Kotlin as a step back, but not enough to
permanently leave Java behind. From that perspective, Kotlin looks just like a
pragmatic compromise. Immensely useful, perhaps, but not exciting at all.

~~~
switchbak
I'm a long time Scala guy, and for some reason at the gigs I've been working
at Kotlin is far more marketable than Scala. This confuses me, as the style of
Scala we've been writing is almost identical to the Kotlin code.

At this point I'm chalking it up to 'better tooling', especially in IntelliJ.
And underscores. People seem to hate underscores. Well, and the Google-stamp
of approval I suppose.

Scala definitely does provide way more ways to overcomplicate your code, but
with a dose of discipline it's quite manageable.

For me, Kotlin does feel like a step back. At the same time the fact that more
people are enthusiastically adopting it means I spend less time selling and
more time coding - so in that sense I'm actually a reasonably big fan.

------
coldcode
There is no one language to rule them all, and there never will be. Compared
to when I started in the early 80's there are enormous choices to pick from
today. When I started I was allowed to pick any language I wanted as long as
it was Fortran. So having new language choices today is a good thing, but it
makes it very hard to pick. As an iOS programmer today I am glad to use a nice
modern Swift. If I did Android I would likely chose Kotlin. If I did server
side I would likely pick Rust or Go or Clojure or Javascript or Erlang or ...
too many choices. Its not about the "next generation" its about picking
something that works for you and your team/project and hope its not abandoned.
No one language is going to be the Next Single Big Thing.

------
stewbrew
Kotlin is a nice language but being tied to jetbrains with no useable
ide/editor around but jetbrain's own idea it won't rise that high. A working
lsp language server would help.

~~~
wpdev_63
I agree that they should implement a language server but they do have an
eclipse plugin[0] that they develop. It's very generous of them to do.

[0]:[https://github.com/JetBrains/kotlin-
eclipse](https://github.com/JetBrains/kotlin-eclipse)

~~~
stewbrew
The eclipse plugin sometimes doesn't provide the best developer experience
though. I doubt they would accept that for intellij idea.

------
tiuPapa
The only reason I am focused on learning Golang rather Kotlin is because I
couldn't find good docs for beginners that don't assume Java knowledge.

~~~
distances
To be honest though, finding programmers with no Java knowledge isn't trivial.

------
zan
Hey everyone, I'm Zan - the person being interviewed. Any questions about the
survey, let me know :)

------
fnordsensei
Please excuse the tangent, but is there any programming language that has done
away with the file as a basic organizing unit of code?

Whenever I consider PL ergonomics (as I do now, in connection with this
article), files come to mind as an incidental inheritance of file systems
past.

~~~
TeMPOraL
Do you have any alternative to files in mind? There are image-based systems
like Smalltalk and some members of the Lisp family, but even in those cases,
sources usually end up being stored long-term in files, as a matter of
convenience.

~~~
igouy
> …but even in those cases, sources usually end up being stored long-term in
> files, as a matter of convenience.

Is that "the file as a basic organizing unit of code"?

Even when code is _organized in applications_ and classes and versions… and
persistence comes from a database, the database will be _implemented_ using a
computer file system.

[https://books.google.com/books?id=ld6E19QIMo4C](https://books.google.com/books?id=ld6E19QIMo4C)

------
adrianlmm
I don't recoment Kotling becuase despite being Open Source it requires a
proprietary closed source IDE to use it, they have plugin for Eclipse but it
will be always a second class citizen and the free version (IDEA) cannot
comapre to Eclipse. To me is just a trojan horse that is heavily marketed by
Jetbrains, even for Android apps I'd recoment Dart with Flutter over it.

~~~
vbezhenar
Idea Community Edition is free and open source. It supports Kotlin with the
same plugin. Whether it's comparable to Eclipse is debatable. I like Idea much
more.

~~~
adrianlmm
Objectively, Eclipse is milles ahead and more complete than IDEA, it is a toy
compared to Eclipse

~~~
eklavya
Having used both I can't imagine what you are talking about. Which features in
Eclipse is Idea missing?

~~~
adrianlmm
First of all, I'm talking about the free version of IntelliJ (IDEA), you
cannot use it to create Java EE applications and the HTML and JavaScript
editors are pretty basic as everything else.

------
weitzj
I enjoy Kotlin, but what is missing is a book: "Kotlin for Beginners".

The current state, as I see it, is: Developers learn Kotlin, not Beginners

So it is not easy to find good learning material to start as a beginner into
programming with Kotlin as your first language.

If you have some resources for me that would be nice - so I can convert more
people.

~~~
AlexeyBrin
Available in the next few days: [https://www.amazon.com/Kotlin-Programming-
Nerd-Ranch-Guide/d...](https://www.amazon.com/Kotlin-Programming-Nerd-Ranch-
Guide/dp/0135161630/)

------
ythn
> First off, I was genuinely surprised by the love students and more junior
> developers are giving Kotlin.

This seems to indicate that the "love" Kotlin gets is mostly fad motivated.
Just like younger generations reject the haircuts and "cool" slang the older
generation uses, the same younger generations reject older programming
languages in favor of fashionable, glamorous, new ones.

Java went from being THE trendy fad language to the old fogey that everyone
mocks and derides.

~~~
zellyn
Java was cool at allowing a couple of things nothing else did: applets, and an
actually cross-platform language.

But the language itself never seemed “cool” — it horribly verbose even from
the start. In fact, it's much better now than it was.

~~~
pjmlp
It was surely cool in 1996, vs Frankenstein C compilers still stuck between
K&R C and Ansi C (hello aCC), C++ compilers playing catch up with ongoing ISO
work.

Then there was VB 6, Delphi, Eiffel, Oberon, Modula-3, Component Pascal,
Smalltalk, Common Lisp and a few others more.

Big difference was that Sun was giving the JDK away for free every way they
could.

Magazine CDs, conferences, sending them free by post, whatever.

I was on my last year and everything that had to do with distributed conputing
or compiler development switched to Java. With teachers carrying Java branded
bags.

~~~
AnimalMuppet
Two other cool things about Java:

The library. It had _everything_.

Garbage collection. You didn't have to keep track of when to free memory any
more. If you were in C or C++, this meant a major headache just... went away.
(If you were in Common Lisp, well, you never had that headache in the first
place...)

~~~
pjmlp
Quite true.

I already used Oberon, Caml Light, Prolog and Smalltalk by then, but it was
the way Sun was pushing it no matter what that actually made it mainstream,
regarding GC adoption.

If I am not mistaken it was Guy Steele that stated it brought developers half
way to Scheme.

As for the library I remember the first commercial Java collections based on
the ongoing C++ STL work, before Java 1.2 adopted their own, with a few
similarities to Smalltalk ones.

C++ on those days had each compiler vendor provide their own view of what a
C++ framework should look like, and although RAII was already a thing, very
few of them already offered some way of doing smart pointers, with the
exception of COM wrappers.

~~~
igouy
> As for the library … with a few similarities to Smalltalk ones.

And the recapitulation of _emulated_ versus _native_ Smalltalk UIs, with Swing
versus SWT.

~~~
pjmlp
Yeah, the error there was that Swing does not have the right defaults, so it
does require some graphical programming skills to make nice UI experiences out
of it, or buying component libraries.

And since a large majority doesn't bother to read books like Filthy Rich
Clients, the outcome isn't the best.

------
bogwog
My takeaway from this is that Kotlin appeals to junior/inexperienced
developers, cargo-culters, and JetBrains developers.

~~~
Larrikin
After using scala, it was hard to go back to Java. After learning Kotlin and
reading others scala code I don't see myself using any other JVM language
besides Kotlin unless I'm forced to. I never minded Javas verbosity because I
liked the type safety, but after experiencing languages without it java just
becomes annoying to right. Scala was great initially, but because they put
every concept ever thought of into the language it becomes a mess because
people pick and choose from all the esoteric options. Kotlin is a happy middle
ground to me.

~~~
eklavya
Easy/common things should be easy and hard/uncommon things should be possible.
So it's scala for me :)

