
The case against Kotlin - PleaseHelpMe
https://medium.com/@Pinterest_Engineering/the-case-against-kotlin-2c574cb87953
======
eropple
This article misses something I feel is really very important: _Kotlin is just
Java_! Like, granted, I'm probably a better-than-average developer, but I was
turning out well-factored, clean, readable, 100% Java-interoperable code in
Kotlin in about a day. Over time I've added more Kotlin-specific stuff (like
their way nicer-feeling collections APIs) but for real, it's just...Java.

But it's smarter Java. It gets out of your way. If you understand Java, the
1:1 mapping between Kotlin and Java is trivial. I can tell you what the auto-
generated Kotlin code from the IntelliJ helpers is gonna look like when you
convert Java to Kotlin and it's just...obvious? The only thing I have ever had
even the slightest trouble with was how to take a var (which I understood
immediately to be a backing field with getter/setter methods under the hood,
both because the doc says so and because IDEA says "from getFoo/setFoo" when
importing Java so it's an obvious intuitive leap) and apply a Hibernate
Validator attribute only to the getter. It was a hole in the docs at the time,
but I figured it out: `@get:Something()`. If that's the only thing that gets
an experienced but largely out-of-the-game Java developer a little head-
scratchy, this should be a slam-dunk type of thing for somebody who writes
Java every day.

Maybe it's harder for Android. (I think you should write React Native for
Android for basically anything you can--and I have, I released a Google Play
app a couple weeks ago that I really should get around to marketing--because
while I am down with Kotlin,I also like being able to actually share code
everywhere.) But Java-to-Kotlin is a no-brainer, in my book, at literally any
Java shop not targeting, like, Java one-dot-ancient.

~~~
buremba
You know, there is a joke that 90% of the developers think that they're better
than average. :)

~~~
szemet
"90% of the developers think that they're better than average"

Median. It can happen that 90% of programmers literally better than the
average.

~~~
mnm2
The few bad/worse developers are then 10% and would have to be really bad

~~~
emodendroket
Is that unbelievable?

------
xiaoma
> _" Developers need to learn Kotlin well enough to confidently read the
> language. While a few developers will self-teach themselves, teams will
> still need to set aside training time for everyone to get up to speed. New
> developers will need to learn Kotlin, and a one and done training won’t be
> enough. In addition, current developers who are trained but rarely touch
> Kotlin may need a refresher if they move to a part of the code requiring
> Kotlin. This means onboarding is slower and you may lose some velocity."_

Are engineering teams at Pinterest really so weak that going from Java to
Kotlin—an extremely similar language—is a major hurdle? The entire mindset of
this article is alien to me.

~~~
strictfp
I'm a lone wolf in the Java space, and I must say that this one really hits
home. I've been dealing with so many Java devs who are unwilling to approach
anything else that I am sick and tired of their whining! These people are even
moaning about JavaScript. I mean - Come On! (Job style)

~~~
sidlls
I primarily use Python, C++ and Rust these days and I would certainly moan
about having to pick up JavaScript.

~~~
celim307
When have you used it last? The ecosystem around it sucks but the language
itself is not too bad, es6 has made the syntax pretty bearable

~~~
fulafel
The semantics is the major pain point. It doesn't flag many errors. Python is
a much easier language to dev/debug in because of this. Also, if you're going
to transpile, why not transpile from a nicer language? ES6 is competing with
ClojureScript/TypeScript/etc.

~~~
srean
Is the 'transpile' nonsense a java script community thing ?

~~~
shakna
Transcompile is very old term in computing, at least the 80s, specifically
referring to compiling from one language, to another high level language.

CoffeeScript simply made the shortened term more popular, but the use of a
more specific term is nothing to get irritated about.

~~~
fulafel
True, but transcompiling hasn't been a very commonly used term for that so
it's not an obvious term to use. For example, the early C++ compiler that
targeted C was not referred to as a transcompiler. Nor was the popular f2c
fortran-to-c compiler.

------
scarface74
I'm impressed by the even handedness of the article.

Normally, I wouldn't even think about using a language developed and
championed by a litle Czech company, however, JetBrain's tooling is incredible
and I gladly give them money every month for R#.

On the other hand, usually I would think that the language being endorsed by a
major company for their platform was a big plus, but the way that Google drops
products and initiatives, their support means little.

So yeah, I trust JetBrains a lot more than I trust Google and if I ever decide
to bite the bullet and start developing for Android, Kotlin will be my first
choice.

~~~
atemerev
JetBrains is a mostly Russian company. It is registered in Czech republic, as
business conditions in Russia are... erratic, to say the least, but most of
their founders and employees are Russians, and their prime engineering unit is
in St. Petersburg, Russia.

~~~
hiram112
Yeah I'd be pretty pissed if I couldn't renew my license to Intellij this year
because of some sanctions passed against Russia due to political BS by our
political parties.

------
wazoox
Well maybe, but _the_ Steve Yegge wrote this:

[https://steve-yegge.blogspot.fr/2017/05/why-kotlin-is-
better...](https://steve-yegge.blogspot.fr/2017/05/why-kotlin-is-better-than-
whatever-dumb.html)

Obviously these guy love Java. This, frankly, I can't understand. I've hated
Java for 20 years :) However if you love Java, obviously you don't need to
switch to Kotlin. If like 99% of people used to leaner languages, you find
Java unbearably verbose, ugly, etc. Kotlin is a godsend.

~~~
eludwig
Agreed. A lot of this has to do with where you came from and what you were
used to previously.

I initially switched to Java in the late 90's from C++. At that time, C++ was
just achieving (imo) its densest, most arcane features that were making me
crazy. What I really wanted was a C+- or something that didn't force a bunch
of stuff I didn't need on me. Java was exactly what I needed at that point.

After 15-20 years of Java, I recently switched to full time Javascript
development and woah! It was like the freshest breath of fresh air. What, no
types if I don't want them? Closures and protoype inheritance? Yes, Omg!

Imagine my dismay when I was first introduced to TypeScript! My code looked
just like Java again. :( Seriously, I understand the reasoning behind TS and
getting into it a little further convinced me it wasn't too bad after all.
Again, what are you used to has a lot to do with your state of mind as a dev.

Any language that lets developers express their intent in the way they like is
great. Kotlin, Scala are like the JS & TS of the Java world. All good (as long
as they work!).

~~~
manyxcxi
In case you haven't played with it, you may find that you like Groovy for
writing Java in a JavaScripty fashion.

I have a ton of JS experience, and one thing that has continued to pain me
with Java has been the arcane incantations required for Async and Closures.

I'd used Groovy just a little bit here and there for Jenkins stuff, but I
finally looked into while building a DSL for our company. Closures are first
class, typing is generally pretty optional, and you can use just about any
Java library. When in doubt, you can always just write plain old Java.

I've become a huge fan, though I haven't started introducing any Groovy to my
existing Java projects as they're mostly Maven built, and I don't really want
to rock the boat.

Speaking of Kotlin and JetBrains, IntelliJ has pretty good support for Groovy,
and follows @Delegate annotations very well for hinting and IntelliSense. I
made my entire DSL type hintable with like four annotations and a 4 line GDSL
file.

~~~
h_r
I'm curious what you mean here with the implication that you couldn't simply
add Groovy code to your existing apps built with Maven. Have you tried it?

It has been probably over 5 years but when I was writing a lot of Java and
Groovy, we were standardized on using Maven at that company. The Groovy Maven
plugins worked and I had several projects with various mixtures of Groovy, all
built with Maven: from Java with Groovy tests, to Groovy and Java throughout,
to pure Groovy web services. It was a bit of a pain getting the configuration
set up initially but it worked well.

~~~
manyxcxi
What I didn't say was that my only experience so far is with Groovy by itself,
and using Gradle to build. It's not an implication of Groovy or Maven for not
supporting it, it's that I don't know the right way to do it yet.

~~~
h_r
You can mix Java and Groovy with Gradle as well. This might help:
[https://stackoverflow.com/questions/22369033/how-to-use-
grad...](https://stackoverflow.com/questions/22369033/how-to-use-gradle-java-
and-groovy-together)

I haven't used Maven in a long time and I'm not sure what is the state of the
Groovy Maven plugin. Writing unit tests in Groovy for your Java projects is a
great, low risk way to get things working.

------
Entangled
Kotlin is here to stay, it's a pleasure to code in it. The same way ObjC gave
way to Swift and I also enjoy coding in it. They both are the only languages I
use today for any development. I don't care about tail-call-whatever,
functional-whatever or monad-whatever, I just care about a nice and clean
syntax that gets out of my way to get the job done in less time. The rest will
be improved by people way more intelligent than me in whom I trust, backed by
two of the biggest players in the development world, Google and Apple.

~~~
smichel17
Note that you can do functional Kotlin with the `tailrec` keyword for
functions.

------
watwut
If it takes a week till new developer feels really comfortable, then it is
quite fast and total non-issue. The article spins it as some kind of problem
you need to be aware of, but realistically it looks like drop in a bucket
compared to what it takes till one get really comfortable with existing
codebase, company standards, processes and what not.

------
mephitix
This reminds me a lot of Swift's early days. Build times, dev stability,
learning curve, static analysis (remember the esoteric compile/lint errors...)
even reversibility (i.e. Apple had a tool to convert from Obj-C to Swift but
not the reverse) were issues that were brought up. If Kotlin hopefully follows
Swift's path then these will get ironed out over time.

------
edem
This article is most likely written by someone who does not like Kotlin but
has to live with the fact that he has to use it. Let's see some invalid
points:

> If you’re going to use Kotlin in your code base, you’ll need to teach almost
> every developer on your team how to use it.

Not true. Java and Kotlin can be used on the same project and Kotlin also has
seamless Java interop. If you don't want to write Kotlin you don't have to. It
is also easy to read for other devs so readibility is not an issue.

Then the writer goes on and on how the velocity is affected by learning Kotlin
but misses the point: you don't have to burn any bridges by using it.

> When I realized very few developers actually saw the developer velocity
> gain, I was left with a bit of a, “so what’s the point” feeling.

Then the op should question the capabilities of his developers. I came from a
Java background and after several weeks of Kotlin exposure my productivity
skyrocketed. It helps if you have some FP background but you can learn it on
the way. Currently the whole team writes Kotlin code and looking back at
previous sprints I can say that the velocity increased by a double digit
percentage.

> Kotlin accounts for about 25 percent of our clean build time and 40 percent
> of our incremental build time.

Then the op has some serious Gradle configuration problems. We also had this
then tweaked Gradle (upped the version, started using parallel builds, etc)
and now the difference is minimal. You are also better off with tools like
JRebel even if you work with Java.

> Not being familiar with Kotlin, the developer immediately assumed Kotlin was
> causing the problem and lost time investigating what was a simple fix. This
> “weirdness” combined with the actual stability issues means there’s
> significant maintenance time lost.

I've been using Kotlin for more than a year and I only had a single stability
issue (and it was an IDEA plugin problem). Kotlin works amazingly well with
other libraries and after using it for several months I felt that I never want
to go back to Java.

Maybe the op's issues are with the Android ecosystem or a bad development
team, and not with Kotlin itself since we use it on the backend and we don't
see the problems mentioned in the article.

The only valid point I've seen in the article is the lack of static analysis
tools and as the article states it will get better.

~~~
bsder
> Not true. Java and Kotlin can be used on the same project and Kotlin also
> has seamless Java interop. If you don't want to write Kotlin you don't have
> to. It is also easy to read for other devs so readibility is not an issue.

Until you have to trace a bug through both codebases.

Dual interop codebases never work. A computer language simply takes up too
much mental space to know even one language well and stay up-to-date on it.

Yes, I know there are exceptions, but I have yet to actually meet and work
with one.

~~~
edem
Not true. Our codebase is java/kotlin and it works.

------
SonOfLilit
Steve Yegge recently rose from the proverbial grave to build a case _for_
Kotlin: [https://steve-yegge.blogspot.co.il/2017/05/why-kotlin-is-
bet...](https://steve-yegge.blogspot.co.il/2017/05/why-kotlin-is-better-than-
whatever-dumb.html)

------
Zekio
Hopefully most if not all of the points mentioned will become equal or better
than Java as Kotlin matures

------
Zigurd
Apple, and iOS developers, need Swift a lot more than Google needs Kotlin. The
main benefit to Google is that Kotlin provides a ready-to-deploy lifeboat in
case Oracle is able to make significant intellectual property trouble for
Google.

------
AzzieElbab
Never read a troll that ended with "we are hiring" before

------
manquer
Well written and thought out, meta issues such as training are rarely
mentioned in comparison pieces but do play an important role in the decision
process

------
swsieber
Well written article. Most of the points made are common sense... but I think
often the points are glossed over and we don't stop to think about it.

------
atemerev
If this is not FUD, what is?

~~~
35bge57dtjku
Why is it FUD? There seems to be a serious split here with lots of people
loving the article and lots not.

~~~
edem
It tries to spread Fear, Uncertainty and Doubt, no?

------
utkarshsinha
Did you remember other languages by Google? Dart anyone?

~~~
klancaster
Google did not come up with this - JetBrains developed the language and use it
to develop their tools.

