Are there any docs/talks about how you sold Kotlin...

# server

[Gopal S Akshintala]

Are there any docs/talks about how you sold Kotlin to your team for backend? I am planning to do so at Salesforce and I need a reference for my pitch. Thanks

[dave]

TBH, it's really no different to any other pitch for adopting Kotlin. Pretty much all of the major libraries are adding support for K . What you're buying is all the good stuff like massive reduction in code-base, type/null-safety and most of all - happy developers!

[dave]

And some big-name companies such as Square are going all in on their open source libraries in K - so if you're using libraries like OkHttp then it's already in your codebase

[Timo Gruen]

Wasn’t able to sell it to my last employer, as they had huge concerns about the learning curve. (Unfortunately business people decided to not use kotlin, and not the developer themselves).

[dave]

Last time I checked, it wasn't my place to tell the business people "how to business". That relationship works both ways.

And if you can't change your employer, change your employer. 😉

[Timo Gruen]

„Last employer“ so basically that’s what I’ve done there 😁 and yes, fully agree to you.

[Joel]

I don't know of a downside to using Kotlin on the JVM. It's compatible with all your Java code, and makes developers happier while saving them a ton of time and reducing bugs. Why would you not use it?

[Gopal S Akshintala]

That's a good point... But the poor thing is, as a part of pitching, I am sure someone will ask me what are the downsides, and if I answer none, they may conclude that I am biased and haven't researched enough 😕

[dave]

This might help: https://medium.com/google-developer-experts/why-are-java-server-side-developers-not-adopting-kotlin-8eb53e06ee99

[Gopal S Akshintala]

Yes I have read this on the day of publication, such a good read

[Gopal S Akshintala]

Thanks

[dave]

also, this:

[Joel]

Java is getting better with each release.

I've heard that a lot. My answer is that Java is looking more and more like Kotlin, which should tell you something. I think TypeScript is having the same effect on JavaScript.

[christophsturm]

also with kotlin you can have the new language features and stay compatible to old jvms

[Joel]

It’s confusing having two languages in one codebase.

You'll be using Java libraries anyways, so I would argue that every Kotlin codebase has two languages. That's the point!

[dave]

"better" apart from the lack of null safety, the awful inconsistent type inference and the quite frankly hilarious collections API..

[Joel]

And does it even support trailing commas yet? 🤣

[Gopal S Akshintala]

Honestly, wearing a hat of pessimist, for someone who hasn’“t used Kotlin before, Null safety” is the only audacious benefit one can sell

[Gopal S Akshintala]

I believe it’s difficult to educate people, unless they have intrinsic enthusiasm and tried their hands-on Kotlin for a while

[christophsturm]

easier immutability was one of the benefits that made me switch to kotlin

[Gopal S Akshintala]

I am sure that makes some devs uncomfortable 😄 they won’t mind using mutable collections without hesitation

[Gopal S Akshintala]

looking at the amount of mutability the codebase has

[christophsturm]

maybe its good if not everybody switches to kotlin 🙂

[dave]

if null safety isn't enough to switch alone (being one of the largest sources of errors in java programs as per SO), then I'd be very concerned about the people who are making the decision

[dave]

one sneaky way to start slowly is to use "Kotlin in tests only"

[christophsturm]

also the learning curve is non existent because you can convert single files to kotlin without changing their interface. and you can even do it automatically

[christophsturm]

and then introduce more idiomatic kotlin over time

[Gopal S Akshintala]

ya that’s what I thought, “hey just tests, no risk :)”

[Gopal S Akshintala]

wish there is a Kotlin to Java convertor, then it’s zero risk

[dave]

no kotlin developer would write that

[Endre Deak]

@Gopal S Akshintala if you have version control, just create a commit with the java --> kotlin conversion result. Kotlin to Java convert is essentially rolling back to the previous version.

[dave]

Intellij already creates a commit for you for the conversion 🙂

[CLOVIS]

@Gopal S Akshintala one of the downsides: if you're making a library, it's not always easy to have the signature be exactly the same as it was in Java (for backward-compatibility). Definitely possible, but it's quite easy to introduce breaking API changes.
Also, if your Kotlin code uses suspend a lot, it becomes a bit weird to access it from Java.

[dave]

That's what the JVM annotations are for. I'd definitely be interested to know of any things that don't work (apart from suspend 😉 )

[CLOVIS]

Also, there “is” a kotlin -> Java convertor.
The quotes are because it produces weird, non-idiomatic Java that sometimes doesn't even compile. So you can't really convert your codebase, but for a developer coming from Java it's immensely useful to understand what's going on under the hood:
In IDEA, at the top, Tools › Kotlin › Show bytecode; select a Kotlin file; press ‘decompile'

[CLOVIS]

I definitely don't recommend to use that for an actual conversion, but if your goal is trying to understand the performance or just “what does this property become?” then it's pretty useful

[CLOVIS]

(if you use inline functions, you'll see that the compiler adds ‘markers' for itself, so you'll see stuff like int v$12 = false; but don't worry about it, the JVM understands these lines should just be ignored, so there's no performance changes).

[CLOVIS]

Depending on the project, another thing I found really nice was to be able to export a small multiplatform library that contains the objects of the REST API (so essentially a bunch of @Serializable classes) that I can then import server-side and client-side : if I refactor the API, the changes are sent to all client implementations instantly—as long as all clients update their binaries, you don't have to worry about breaking changes anymore.

[Joel]

@CLOVIS that's a solid idea. Can you compile it into a TypeScript project?

[dave]

might be useful for this discussion:

https://www.youtube.com/watch?v=0V-qp-qpjzU▾

[CLOVIS]

@Joel do you mean the multiplatform bit? You can definitely compile it to JS, but I have no idea if it generates TS headers as well. It's just the normal multiplatform plugin though so that info should be easy to find ^^

[CLOVIS]

I recently started a project on fullstack Kotlin (JetBrains Exposed – Ktor – Multiplattorm – Jetpack Compose/Compose for Desktop
It's the very early stages so there's nothing very interesting to see at the moment (apart from the Gradle config I guess), but hopefully with time it should be pretty interesting: https://gitlab.com/braindot/clovis

[dave]

Also... https://aws.amazon.com/blogs/opensource/adopting-kotlin-at-prime-video-for-higher-developer-satisfaction-and-less-code/

[Joel]

Ha, I was just going to say that their async code isn't parallel and then in the next paragraph they mention dispatchers.

[Joel]

I completely forgot about extension functions, that's a huge win in Kotlin. I also wonder if we'll get partial classes some day.