"Kotlin does for Java and the JVM what Spring did to J2EE”
— Spring creator at SpringRod
I have noticed that Android and Kotlin are increasingly becoming synonyms, especially in the minds of IT recruiters.
It's a very understandable error. They are doing a different job and a good recruiter is not required to know everything that we know, he needs to do his own job well.
But it is wrong:
As you can see on this schema, Kotlin has a larger share of usage in Android than on the JVM. But since the JVM is a bigger platform, the number of Kotlin developers that do Android or something else is roughly similar.
In the Android world, Kotlin is replacing Java
The background on this is that the Android world is becoming fast Kotlin first.
Also there is a very tempting parallel with the Apple/iOS world where Swift is replacing Objective C.
Apple is pushing Swift.
It seems that Google is pushing Kotlin in the exact same way.
Some early articles even used this parallel explicitly:
"Kotlin, the Swift of Android"
... but it's not so simple
Kotlin was designed for Java and the JVM, not for Android
Kotlin was created by JetBrains, not for Android but for Java and the JVM.
That's a big difference with Swift/iOS.
The programmers interested in Swift and in iOS/macOS are basically the same.
On the other hand, while Android is a big platform, Java and the JVM is an even huger platform.
This explains neatly that while Kotlin is a big hit on Android, there are still as many or more Kotlin developers that are not programming for Kotlin.
Source: https://www.jetbrains.com/research/kotlin-census-2018/
Kotlin on Android is all about product-market fit
So why was Kotlin a big success on Android if it was not designed for it?
Simple, it's a classic example of product-market fit.
JetBrains did not target Android developers.
Android developers world realized themselves quite clearly years ago that programming for Android was broken and needed to change.
I wrote about it here
So Android developers were actively seeking new solutions, trying out everything until they found something that sticks. And one of those things was Kotlin.
That's the context of what you have read
Google is now pushing Android as an official language on Android
It was not in fact like Swift which was invented and pushed by Apple for iOS developers.
Instead Kotlin was intended to replace Java, the Android developers discovered and used it first.
Then the Android Framework team decided to follow them.
I am certainly glad they did.
It does open new hopes for making developing for Android less painful.
And also it made the signaling much easier.
This is why dear recruiters you have heard the message that it was OK to use Kotlin in Android.
But in fact it was totally OK even before this was announced.
The Java/JVM world is in a very similar position today
Today it's perfectly OK to use Kotlin on the JVM.
It's just that as an IT recruiter you may not be told explicitly to recruit for Kotlin backend developers.
I propose this rule of thumbs:
if Java is a good solution to a given problem,
then Kotlin is a great solution to the same problem
In particular Kotlin is a great choice for backend developers.
It has its own very interesting native frameworks.
And also it is pushed by the Big Guys from Spring and Spring Boot
Kotlin coroutines are changing the game because you don't have to choose between simple code and non-blocking code anymore. Why not both?
Recap
- There is a lag between when developers start using a technology and when recruiters are told to hire for that technology
- Android is becoming Kotlin first and 50% of Kotlin developers do Android
- The Kotlin+Android devs are highly visible and hard to find. If I were looking for an Android developer, I would focus on good Android developers that are currently using Java. Those can be more easily to learn Kotlin. Learning Android on the other hand is hard.
- Keep in mind that 50% of Kotlin developers do something else than Android. Those people gets a lot of job offers for doing Android and are getting annoyed by it. So if your company is Kotlin-first on the backend, you may want to do more marketing about it.
Top comments (7)
Another post bashing one language to rise another. As a rule of thumb Kotlin developers want it to be better than Java for same things. Some people dissagree. A lot od them actually, and ignore the language battle. Groovy is the one that made a huge jump in short period this year. Kotlin actually fell. Are some stats biased? All are but it still doesn't make Kotlin better than Java. Both languages are limited actually. Neither is better. If you need to be better than someone to have a purpose you are not that useful. Why would I switch to Kotlin? I have C#, Scala, Groovy, Elixir... Do I need more languages? Pick one good for the task and make a product. Being better for sole purpose of being better has no influence on people. That's why Kotlin is associated with Android. We don't care what it says we care about how pragmatic it actuallys is. Same with the patterns and everything else in the industry. If it's good to do TDD because someone said so go do it. Some need to deliver product in less time and more user oriented not philosophy oriented.
🤔🤔?
The article is about the misconception that Kotlin is limited to Android.
It's not.
Kotlin is a great fit for me for doing backend programming on the JVM.
I'm not sure where you have read that I was bashing other programming languages.
I'm no fan of bashing other technologies that others find useful in their particular context.
Exactly the point. I came to read problems about Android being interchangeably used with Kotlin which is easy to understand because of JavaScript = Java problem from before :). But things like "I propose this rule of thumbs:
if Java is a good solution to a given problem,
then Kotlin is a great solution to the same problem"
are what this article has related to bashing. I did not want to rant about how someone is bashing something but more to open eyes of the writer. Things like the ones mentioned are actually this technology > other technology. That's what bugs me and I need to question it. I tried C# and Kotlin. C# was much better but I disliked the .NET Core in comparison to Micronaut & Spring. Kotlin was a pain and I had no actual benefits of it for my use cases. So I came here to see maybe something more than Kotlin > Java. And still not more than that I found. I guess you see the point now of why I feel this article had some bashing in it. I know it's not your intention but do try to understand of why someone might feel that way.
I understand now why you reacted this way, you took my "rules of thumb" as an hint that I wanted to bash Java.
But really my intention was something else than bashing anything.
I do think that Kotlin is great for me (but happy that you have found something better for your needs). But the reason Kotlin is great is that it is standing on the shoulders of Giants
A Tribute to Java. Java-bashing is a popular past-time and… | by Roman Elizarov | Medium
Roman Elizarov ・ ・ 6 min read
Medium
Back to my article: I am a Kotlin backend developer and I receive almost every day a job offer to do Android... which I really do NOT want to do.
So I wanted to explain once for all that there is more to Kotlin than just Android.
The rule of thumb is to give recruiters a better idea of where Kotlin makes sense : mostly in the same areas where Java makes sense.
Very valid points. I switched from Java to Kotlin for backend work in the last two years and at this point it's very clear that if you are not using Kotlin for doing anything Spring related, you are missing out on a lot of things. They still support developing in Java but it's just that they are increasingly targeting Kotlin.
From personal experience, Kotlin makes using Spring a lot nicer even without all the Kotlin specific stuff. I had a Spring 4.x project where I introduced Kotlin and it worked great. Kotlin is designed from the ground up to be drop in replacement for Java pretty much anywhere. This is why it made so much sense for Android development as well.
However, with all the Kotlin specific stuff that landed in Spring 5 & Spring Boot 2.x it went from "it's really nice to do this stuff in Kotlin" to "if you are not using Kotlin, you are probably doing it wrong". Reactive without co-routines is painful. Doing entities without proper data classes is ugly. And having some immutability and null checks by default is also super helpful.
Also, check out what they are doing with Kofu: github.com/spring-projects-experim.... If you are looking to run Spring applications using Graal, this will be the way to go in the future.
The Android thing with recruiters is annoying. Reminds me of when people associated Java with mobile phone games or applets (way back).
Feel free to answer every Android offer with this URL, this is exactly why I wrote this article :)
Great! Thanks for sharing the experience