How have or would you sell Kotlin to your team?

1

I am personally sold on using Kotlin over Java. We are doing REST API development currently in Java using TomEE 7.0.2, JAX-RS, etc.

We already have a few things in Kotlin now, including Akka and Kafka, but our whole team is not yet onboard. One developer on my team seems to be against for various reasons, some including “well if we go Kotlin why not just Scala since Kotlin just copied most of Scala”. He seems to forget or not understand that moving to Scala also includes a bunch of other stuff like sbt, play framework, so all new tools and framework, whereas with Kotlin, we keep the same container app server, shared libraries, Java EE, etc just a better language.

I’m not sure how to do a better job at convincing my team and bringing the others along. We have architects who are questioning why we would build new microservices in Kotlin instead of just java (they also happen to be Scala developers so slightly bias).

I’m becoming frustrated. I am the dev lead, so this is a great leadership opportunity but a hard one.

Some arguments that come up are on “who is JetBrains” and that Kotlin is brand new and just released in February (I’ve tried to explain the google-like beta for five years to no avail). This same developer claims there is no Kotlin community. Looking at Tiobe index, Scala is like #36, Kotlin is not on the list.

Has anyone else successfully navigated these waters?

Another argument is “well when we do a search for akka, we will find results for java or scala, and now I have to context switch to figure out how to do it in kotlin”. Or learning curves associated with quirks or ways of doing things in kotlin. To me its no big deal, but hard to explain. Learning any new language comes with learning curves, I argue that I was able to pick up Kotlin and rewrite one of our APIs in a weekend. After a weekend trying Scala I never even got a working test endpoint.

Another troubling thing is the confusion and mixing of arguments of java-vs-kotlin, and then kotlin-vs-scala.

1 Like
2

I experienced many of yours doubt, the last one for a SVN → Git migration.

You cannot lead a flock with care of every single sheep, you may plan a progressive migration helped by the “sheeps with the bell”.
When the confidence in Kotlin is adeguate and everyone can find easy a proper support your team is ready to switch.

Errata: Kotlin is in TIOBE index TIOBE Index | TIOBE - The Software Quality Company

3

I haven’t tried to convince a team to switch to Kotlin, but having used Java, Scala, and more recently, Kotlin, in some projects, I would highlight:

  • In terms of Kotlin vs. Scala, Kotlin brings functional programming features like Scala does, but with more of an emphasis on Java-interoperability. For example, Scala introduces a whole new collection class hierarchy, which is incompatible with Java collections. Also, Kotlin properties generate JavaBean-compatible methods, which is great for working with libraries such as Jackson.

  • A focus on immutability, especially with respect to collections. I think you could discuss how Kotlin makes using immutable data types and collections easier with a much simpler syntax, while retaining Java interoperability.

  • If your team has already done some work in Scala, how did that go? Did some of Scala’s more complex features, such as implicits, cause any issues? Did people appreciate the more concise syntax? If your team is already using two languages for API development, maybe adding a 3rd is adding too much complexity? You may need to address that.

  • What’s the number 1 feature of Kotlin that you think will benefit the team and your work? Perhaps you can show a side-by-side implementation with Java and/or Scala to show the benefits.

Hope this helps…

4

Thanks for the replies!

We are not doing Scala, but it came up as a consideration as we look at a roadmap for the next year, and what our next “evolution” of microservices code looks like.

Two of our CW developers provided feedback that it only took them 1-8 hours of rampup on Kotlin, which to me is the waving of the flag for “look, we can take any Java developer and they are quickly productive”. Scala from what I have read would take a long time.

The issue and reason we said no to Scala is that we are a Java EE/TomEE shop. So if we went Scala, you could use container-based app servers, JAX-RS, Java EE, but even Scala consultants told us why would you do that? Whereas Kotlin is “Scala, the good parts” or “A better Java”, while retaining all of our known tooling/frameworks/app servers/patterns.

The two big arguments we are down to is context switching required when googling for answers/examples and finding either Scala or Java and then having to convert to Kotlin, and fluidity in technology changes. I call bunk on the examples one a bit as Kotlin is so similar I have not personally felt a challenge here.

It’s hard to say what just one or two killer features are. I’m trying to line us up to go async/reactive while staying within Java EE (AsyncResponse, CompletableFuture, Akka) while getting the goodies of expressive, concise, better functional programming, null handling, and well there are 20 great features of Kotlin.

I think the idea of a side-by-side would be good. I swear I did this for the team already, but months ago. I’ve already proven out that Kotlin works, we have production code using it with BatchEE for some batch jobs, as well as a kotlin+tomee+swagger+akka POC.

Bringing others along is a hard skill to master. I see this as the future, and a good decision. I call bunk on arguments like “well who is JetBrains, what if they go out of business”, especially when this developer clearly knows who JetBrains is as we use 3 of their products and every single API / Java dev here uses IntelliJ. We don’t ask the question about who develops nginx when it runs everything we do (okay language versus web server, not apples to apples).

5

I have a bit of a different take on this: An appeal to beauty.

C is a beautiful programming language. C++ is not, and once the STL came along, it got worse.

Java was originally a beautiful language/environment: Beautiful in its simplicity and consistency. It was basically Smalltalk with C syntax, and more static typing. In many ways, it was the language C++ wanted to be but couldn’t, due to C++'s need for backwards compatibility, it’s design-by-committee flavor, and it’s ruthless quest for runtime efficiency.

Over time, Java has (quite sensibly and necessarily) adapted to things like new concurrency models, dependency injection, and all kinds of other stuff. It’s done pretty well, but along the way it lost the beautiful simplicity that it had at the beginning.

Scala was a great attempt to make a more modern Java, but it came in wide of the mark. Unpredictable implicit conversions, and a constant need to think about “what’s really happening” (by falling back on the underlying Java) remind me of nothing so much as how when programming in C++, one constantly had to refer back to C. Scala is a noble effort, but it’s not elegant. It’s not beautiful. Programming in Scala is not joyful; it’s bureaucratic and frustrating, riddled with surprises.

Kotlin got it right. Kotlin is fun. It’s elegant. It’s a “more modern Java” that delivers on the promise of making programming intuitive and fun and natural and beautiful. Kotlin will make you happy, and happy people do better things.

6

Every team is different in what they collectively value, and if you can identify what that is you might be able to shape your argument to close the gap. Is it stability? Long term supportability? Productivity? Innovation? Power features? Talent availability?

My team values productivity and accessibility more than anything else. We build tactical JavaFX applications (and I helped with the Kotlin TornadoFX library, shameless plug). My team was resistant to any new language until I showcased Kotlin to them. Reducing a massive boilerplate delegated class with hashcode/equals/toString()/builder implemented to one line of code is something they could not argue with. When they asked about adoption elsewhere I said it has become the Swift of Android, and also becoming adopted heavily on back-end. The fact it takes Java devs only five hours or so to learn helped too.

We’ve been using Kotlin since April 2016 in production. They’ve been pretty happy with it and the transition and learning curve was pretty quick.

So again try to find what they value. I heard some folks introduce Kotlin to their workplace with unit tests, which is something that’s less threatening but brings exposure to it. Good luck!

7

you could take all responsibility of using kotlin in production on yourself, and then results will show what was ok and what was bad. Or you could simply fork all your production code, convert in kotlin and test on testing server)

8

The amazing thing from Kotlin is that is very easy to integrate with a Java application, that way you can take advantage of the good things of that language where you want.
As a very basic example, start with DTOs, declaring them in one line and when they are related even together!
This is what we did, and we are expanding more and more the usage, simply because the people see the point.

9

For what it is worth I also find that it can be really hard to “sell” this sort of change to an existing group that is already reasonably happy and settled. History suggests there are times when “better technology” loses out - I hope the Kotlin Team are not too “passive” or “complacent” in that perhaps this won’t “just happen” … there is “selling / pushing” to do.

For me the existing group is pretty content with Java8 + Groovy. Some of the really strong points of Kotlin vs Java8 are where compile static Groovy has already taken over. Kotlin has “some niggles” relative to compile static Groovy at this stage and Groovy also has integration with testing frameworks being used.

For me I need to find a niche where Kotlin can be introduced (like DTO’s or Tests etc). Unfortunately for my scenario the DTO niche is already taken by compile static Groovy (and Kotlin shows niggles relative to Groovy here), the test niche is dynamic Groovy/Spock based, and Kotlin 1.0 wasn’t Java8 focused (so there are some niggles relative to plain Java8).

Kotlin 1.1 will hopefully sort some niggles like the Java8 specific support. Ideally from my perspective there is a real desire in the Kotlin team to make Kotlin “look” at least as good as Groovy syntax wise. Although this might sound a bit superficial “looks” are important when pushing the introduction of a new language to a dev team and sometimes I get the impression the Kotlin team are underestimating this aspect - that syntax issues relative to Groovy are not being addressed or prioritized.

10

For fun (not flame war) here are some personal opinions / comments / feelings related to the TIOBE index

  • Scala is niche and for my money it will stay that way
  • Groovy is the real “competitor” that Kotlin should line up (and aim to take a lot of that Groovy space)
  • With Java9 and Jlink we will get the ability to build relatively small self contained runnables/exe’s … and that means Kotlin + JVM 9 + JLink could target some things that are now done in Go. When the JVM additionally gets values objects we are going to have a pretty wide sweet spot going further into the native space.

There is a very bright future for Kotlin on the JVM if these things line up in a timely manor.

11

Thanks for all of the replies! There are some great points here.

Myself and our other lead ended up chatting with our manager and made the executive decision to move forward with Kotlin. After going through the site, examples and other slideshares, I had a 35-point, non-exhaustive list of features/benefits. Kind of hard to say one or two theoretical concerns outweighs all of the benefits.

On my plate now is to compile all of these into a presentation and spend an hour and a half with the team.

1 Like
12

Did you posted your presentation somewhere ? I’m interested in :slight_smile:

13

The google doc above was one artifact, I’m trying to find the 35-point list, I think it may have ended up just being an email out.

14

Also, I think I “borrowed” most of this from a slideshare I came across or something, just remember this was meant for showing internally to my team.

1 Like
15

Okay and here is the compiled list of stuff

  • Data classes
  • Default parameters/arguments
  • Named parameters/arguments
  • Filtering lists
  • String interpolation
  • Pattern matching
  • Pairs
  • Ranges
  • Immutable collections
  • val/var
  • Type inference
  • Easy map access
  • Lazy properties
  • Extension functions
  • Objects (aka Singletons)
  • If not null shorthands
  • Elvis operator
  • Execute if not null
  • Return on when statement
  • try/catch expressions
  • if expression
  • Single-expression functions
  • with() method destructuring
  • use() try-with-resources
  • Classes in any files
  • Null safety
  • No checked exceptions
  • Destructing collections
  • Field-based property access
  • Delegated properties
  • is/is not
  • as aliasing
  • Zero-overhead lambdas
  • Compile-time function inlining
  • All essential functional facilities (filter, map & flatMap, take & drop, first & last, fold & foldRight, forEach, reduce, and anything else the pragmatic functional programmer’s heart longs for)
  • Target of 100% java interoperability
  • Concise syntax
3 Likes
16

Nice presentation @brandonlamb

Its a 5min quick recap of what we understood about Kotlin.

17

@brandonlamb, thanks, great list of features.

But I think that the best selling points to Java devteam are:

  • Greatest thing: Java codebase will benefit from Kotlin code/libraries because of inserted @Nullable and @NotNull annotations visible from Java call site.
  • Those annotations generated by Kotlin compiler will indirectly reduce NPE issues in Java.
  • This handled well in IDE’s (check IntelliJ IDEA 2016.3 Help :: @Nullable and @NotNull Annotations)
  • Language fixed lots of annoying Java design flaws, like:
  • concise POJO declaration (solved by data classes)
  • singleton design pattern (solved by object classes)
  • static methods - not OOP concept (solved by extension functions and companion objects)
  • missing core immutable collections (solved by Kotlin standard library, 100% compatible with JCF)
  • verbose generics (solved by Kotlin Generics)
  • many Java puzzlers targeted (more details here: Kotlin vs Java puzzlers - Svetlana Isakova on Vimeo)
  • hard-to-develop DSL’s (solved by extention functions and extension functions with receivers)
  • operator overloading and check for equality, not identity (solved by == operator, etc.)
  • declarations redundancy (solved by var, val, primary constructor, etc.)
  • Java language concept of checked exception (all exceptions are unchecked)
  • Java method overloading maintainability (solved by default method parameters)
  • No need to wait for a new project, Kotlin can be easily integrated into existing Java project.
  • No “black magic” under the hood: every Kotlin language feature can be easily explained to Java guy.
  • Kotlin classes/annotations/enums/objects/companions/interfaces looks pretty convenient from Java side.
  • Almost all NPE/KNPE exception stacktraces leads to the place, where the non-null object becomes null, thanks to inserted precondition checks by Kotlin compiler.

IMO, this is the most important improvements that can help java devteam to produce more stable code in less time.

2 Likes
18

I would like to add this.

Destructuring Declarations is another cutie to create variables seamlessly.

19

In my company ,only two android developers.
My partner is a new programer. so,It easy to sell Kotlin. cat: