Slightly unusual question - I've been using Kotlin on the server side for 3 years now, and I love it...

# server

[Rob Elliot]

Slightly unusual question - I've been using Kotlin on the server side for 3 years now, and I love it. I'm working for a smallish startup and I'd like to work in Kotlin, but while they also like Kotlin they are worried about it from two perspectives:
• ability to hire, for the foreseeable future (so now and in 3 years)
• long term prospects for the language - will it still be alive and well on the server side in 3 years time?
Basically there's a "Java may not be as good but in 5 years' time it'll still have a massive recruiting pool and still be evolving" feeling.

Does anyone have any good stats on the adoption of server side Kotlin that might help with this decision?

[Eamon Keane]

while it doesn't go into detail on Kotlin, this has a good recent overview of Java/jvm.

If you're at a startup they should absolutely go for Kotlin, you probably want to hire devs who like learning new stuff, and it's not like you need to hire 1,000 devs, only say 10 or 20.

It'll help you attract experienced java devs who've learned kotlin on the side and want to use it.

AWS have an internal kotlin adoption team helping convert java teams to Kotlin, so if they're doing it, I think you can be safe assuming there'll still be an ecosystem. Also Doordash have migrated from python to Kotlin, so it's becoming the default for tech-forward companies.

https://www.infoq.com/articles/java-jvm-trends-2021/

1Java-JVM-2021-1641381269225.webp

[christophsturm]

my experience is that experienced java coders love to try out kotlin, and that its also easy to introduce them to kotlin, and sell it as a java with less boilerplate and enforced best practices (like immutability). a lot of the knowledge of a dev is also the library ecosystem so they can just continue to use their favorite libs (even if they probably will not be their favorite libs much longer), and even write kotlin code that conforms to java apis

[Rob Elliot]

Thanks, that's very helpful!

[Eamon Keane]

One other point - Kotlin Multiplatform Mobile looks set for breakout adoption, meaning if your company has Android or iOS apps you could potentially use one language for a large portion of your business logic.

It'll become the obvious language choice for new companies who need to churn out web/ios/android and backend biz logic on a budget. Rust for other 0.5% non-application stuff.

[kqr]

what I can see, I see lot of adoption of kotlin in new projects and it's more attractive if company propagates usage of kotlin. converting java developer to kotlin is easy in my opinion

[kqr]

only "downside" I see is "mandatory" usage of intellij, but again most of people/company around me use jetbrains products

[christophsturm]

another downside: intellij idea java features are much more stable than the kotlin plugin, and jetbrains keeps mentioning new java features every week in their IDEA eap postings, while keeping the kotlin plugin at old versions until the release.

[christophsturm]

which is very suprising but has been true for the last 2 years at least

[Jilles van Gurp]

I think it's increasingly the other way around. You'll have a tough time finding people willing to downgrade back to Java from Kotlin. I did a small Java project a few months ago and it definitely felt like that. It's a one way street. A lot of Kotlin developers that could do Java are probably not going to line up doing that if they have Kotlin projects to choose from as well.

Also, if you are using Spring and you are not using Kotlin at this point, you are basically doing it wrong. Yes you can do it but you are missing out on a lot of really nice things. E.g. Spring Flux is an unusable & convoluted mess but with co-routines hiding all the madness it becomes very straightforward to non blocking APIs.

The long term prospects for Kotlin are very good. It's widely used and rapidly growing and maturinhg. It has a lot of momentum and you should start seeing it pop up in more domains than just Android and web servers very soon (IOS, wasm, desktop apps, etc.)

[antonarhipov]

I've heard stories that small companies have used Kotlin as an HR tool to hire the Java devs. The market is overheated, it's hard to attract devs even with high salaries. Kotlin is that extra cherry that you can offer to attract the potential candidates choose your vacancy.

[Dan Rusu]

+1
Kotlin was the only reason that I joined my most recent workplace. I wasn't too keen on the business but really wanted to work with Kotlin on the backend so I was really excited about joining (best decision I ever made).

[antonarhipov]

Also this:

https://twitter.com/_JamesWard/status/1486000363551477765

[Damien]

I doubt there would be any issue hiring for Kotlin. You could pretty much hire any experienced Java developer and they'll be productive very quickly.

[DALDEI]

I consulted for 3 months at a OldBrickAndMorterBank in Chicago. 100+ year old that had gone 100 years outsourcing IT and decided it was time to start bringing IT in house. The project I was involved, one of many, about 50 developers, primarily contractors from large contracting houses (did I say 'bring in house' -- well having the project managed in-house was what that meant, not the 'cogs'). They had bought into 'full agile, CI/CD microservice end to end' and the whole project was Kotlin/SpringBoot. None of the developers had ever used kotlin before, but it was never an issue. At a training class I asked about their experience and skills with kotlin. The general self-assessment was 'moderate' -- i.e. they felt their own skills in kotlin were 'average' -- . I was tasked to do performance analysis and architecture review. The interesting-to-me takeaway -- was that the fact that kotlin was used was rarely mentioned and never an issue. There was tremendous issues with the project as a whole -- but none of it was related to the language. Performance issues were largely niece misapplication of microservice patterns and a methodology designed to guaranteed that good ideas were thwarted before they could infect others, agile stories refined to the level of single cells in a spreadsheet, data formats chosen based on familiarity not applicability, piles of dead code untouched lest it decrease the numeric value of unit tests passed.
But where there were no problems whatsoever, nor much discussion -- was kotlin. The developers had no problems at all learning and using it consistantly in a large project. Defects due to things like array bounds, null pointers, incorrect type or signature, language or function performance etc -- simply non existant.

that left room for the Really Big Problems -- of which there were many. But kotlin ? no. it was a no-brainer, non-issue.
no difficulty hiring nor using at scale.

[antonarhipov]

@DALDEI this message alone would make a great post on Reddit/YC to support those who are in doubts about adopting Kotlin for services