Thank you for joining us today and let's start with a brief intro, probably, of our speakers.
All right, thank you. Thank you all for being here. I'm Marco and I'm Kotlin GDE based in Berlin.
I'm Italian and today I'm here talking about Kotlin.
Same here. I'm Sergey. I'll be talking about Kotlin as well and we were asked to get you the state of Kotlin, whatever it means.
I worked for various companies in Kotlin for about seven years now, I guess, such a long time.
Early years with the backends in Kotlin now mainly in Android development and infra.
But let's start with important things.
We live in a modern time with modern technologies available and so this presentation is powered by generative AI.
It's really important to remember that the speakers today, both of us, are not anyhow affiliated with any companies that create Kotlin
or sponsor it or anything like this. It will be pure, our opinion based on our experience or guesses, I don't know.
We might be wrong except for the places when we are right. That's it for today.
And generative AI make a thing that probably the speaking these days will be an easy job.
Last year, preparing for the FOSDOM talk, I've been writing my videos about 3 a.m. before the deadline.
Nicola was already saying why you're not sending me the videos and I had to do and this year I thought, all right, I'm using the modern technologies
and ask chatGPT to generate the slides for me. Unfortunately, we ended up in like 5 to 10 minutes saying,
oh, I have no idea what is Kotlin because I don't have data after 2021 probably.
So the rest of the presentation is really not powered by the generative AI. I'm sorry for this. So it's powered by us.
And we had to figure out what is Kotlin and what is the current state.
So probably the first reasonable thing thinking about this is to get and try to understand any of the developer service available.
And one of the most interesting one in this domain is the JetBrains developer survey that they run, I guess, every year from 2019 or 2020-ish.
So here is the data available on the end of 2022.
And we can see definitely a domination of mobile development in Kotlin and presumably it's Android mobile development, I guess so.
And another leading stream is the web or backend development which is rising and like 40% of all Kotlin engineers are working with backends.
I must admit that at the end of like 2022, the majority of population is still in mobile, the backend is rising and backend is trending up.
I was under impression like a year ago that, hey, Android is probably the only platform for Kotlin.
However, I was like reasonably biased with this and the first time after COVID when I arrived to one of the European conferences that had a few topics there,
I was impressed that the majority of topics were with backends.
But today let's try to avoid getting too deep into particular Kotlin platforms and focus more on like high-level language stuff, what is coming in the next years, or at least what we can probably predict to come.
It's quite funny that it's possible to describe the whole 2022 and 2023 agenda in the Kotlin world with just five letters.
And one is common in both of the words.
It's K2, the new Kotlin compiler that's coming, and the Kotlin Multiplatform or KMP.
So I'm not very surprised that in the past year we didn't see a lot of Kotlin language features and there are a few reasons for this.
And we'll definitely discuss them in the next slides and further in this talk.
But let's try to first understand what is K2 and what is what it's preparing for us as developers and product owners or engineers.
And then we'll get to KMP later in this presentation.
First of all, there are a few major problems in the whole Kotlin infrastructure.
And they are the stability and performance of the ID.
So even though probably IntelliJ is one of the greatest product on the market for developers, it's not great for Kotlin.
I mean, it's fine, but whenever your project is growing and growing and growing, and I know something about large project in the industry, it's getting unusable.
The second thing is build speed.
Like whenever you tried probably Java for its builds before, even if Java is slow, but overall Kotlin is significantly slower.
And this is like a drawback, especially if you came from the legacy code base whenever you had like five or 10 years of previously Java code.
Yeah, I know, I know, I tried to say we are not getting deeper into the platforms, but it is what it is.
And the build setup overall is quite complicated.
So for example, Kotlin multiplatform, how to run Kotlin multiplatforms from the common line.
If you can give me an answer, I will just take you out for dinner probably.
And currently the overall K2 is developing in the two major Kotlin roadmap milestones.
Like whenever you're interested was going on in Kotlin, you can get to the Kotlin roadmap.
Thanks a lot for publishing it to JetBrains.
It's like magic.
There are two key things like getting K2 to better.
Kotlin is currently in alpha and it's the whole rewrite of the compiler front end.
Meaning that if you previously hacked something for the compiler plugins or compiler infrastructure,
or you're an owner of the libraries like KSP or KAPT,
you basically have to redo everything you did in the past three, five years.
The second part is the IntelliJ-based plugin and the story there is the compiler and the compiler front end
especially is very coupled with whatever Android Studio or IntelliJ IDEA or your IDEA of choice is doing with the language.
Whether it's a language server or the index you have locally, your compiler performance really impact the experience you have in the IDE.
Let's get to the other things.
Like the unfortunate is the deprioritization of the API for compiler plugins.
It means that for all of the engineers outside of JetBrains,
it will be still very hard to create tools for a compiler for IDE and evolve them over time.
Currently, you don't have a stable and you don't have basically a documented API for the compiler.
For example, if you're creating a library that changes something, every major or even minor release of Kotlin,
you need to upgrade it and evolve and maintain the compatibility of the version for the compiler.
Currently, K2 is in alpha, but as far as we understand, the Kotlin 1.9 is about to get us K2 in beta.
For the current numbers, we have the improvement at around a rate of 2x for all the build that JetBrains provided us in their benchmarks
and publicly told us about these things.
Kotlin itself has been building significantly faster.
But if you're impatient, there is the way to bring at least some of the improvements for the build speed earlier in the pipe.
You can get to Kotlin 1.7 something and it has probably 10 to 15% improvement in the build speed.
You can even experience this in the large-scale code bases.
There are a few plans about the K2 going to beta and mainly what JetBrains and Kotlin wants to achieve.
It's the full functional compiler and it should work for the whole ecosystem, not only the JVM.
It's probably usable for JVM even right now, I tried it.
It's not a great experience, but you can experiment at least with it.
There is a need for improvement in various plugins like Kotlin annotation processor, serializable, KSP and others.
It will take time.
As of yesterday, there is a well-done support for Kotlin X serialization.
All open, no arc plugins and Lombok.
It's already in the source code of Kotlin compiler.
I'm not sure which version they're targeting, so I was checking 1.9 daily build and it was fine there.
Probably there is something in 1.721, but I'm not quite sure.
Unfortunately, KAPT is still not working, so you cannot do any of the annotation processing yet.
KSP, the symbol processing, the future of annotation processing for Kotlin also doesn't work.
Let's get into some details of the annotation processor support.
Luckily in Utrecht, there are tickets for almost everything that works or that doesn't work and what JetBrains is planning to work on.
There is a ticket for front-end IR support for KAPT.
It's still in progress. It should be done in 1.9, or at least it's the current version now.
I tried to understand what doesn't work right now, and it got me to quite interesting things.
That KAPT currently doesn't support language version 2.0.
Please use language version 1.9 or below. It's just a source code that I saw yesterday.
I tried to get deeper so that there is a Kotlin version introduced that has symbols both 2.0.
I probably don't want to make any judgment here what the version would be,
but there are some things that suggest that we are going to have some major changes in the future.
Kotlin symbol processing is another thing that doesn't work currently, but it's expected to get around 1.9.
There is some work going on in the domain in the Google repository for KSP, but still nothing there done.
The testing info doesn't work at all currently, so one of the major libraries for the compile testing doesn't support K2.
I don't know when the support will come there. There is a poor request getting this support, at least partially,
but who knows, probably will take another six to eight months.
Finally, the IDE support for K2.
As far as I understand, the plan is to create the K2-based IDE plugin
that will probably start from a quite lightweight one that will support only a few things.
It should have the performance that is targeted to be. Everything works fast and correct and likely stable.
The IDE plugin will have a lower number of features, will be lightweight and will be released
likely after the better or stable of the compiler, so it's not earlier than Kotlin 1.9, probably even later.
As stated currently, it should have all the code highlighting.
It should have basic code completion, like nothing fancy, probably just the stuff you use on a regular basis,
but not for major refactoring or anything else.
In debugger, there should be breakpoints and some simple stuff, really simple stuff, as it's declared,
and there should be a limited number of diagnostics.
The last but not the least thing, as you might notice, another big part is the Kotlin multiplatform support.
This new lightweight plugin is aiming to have the full-featured Kotlin multiplatform support as well.
That's my third. After some key to magic, let's try to check what went through this year of Kotlin multiplatform
and what will come in the future.
Let's start our journey from Kotlin 1.6.20.
The first magic things, beautiful things that we saw, was the Ierco project structure becoming default.
This thing was such a bless, because you finally don't need anymore to do some weird magic stuff like symbolic links and things
to cover multiple architecture like iOS version and Intel version and X64 version.
You get automatically shared stuff and you can just use an intermediate target for the thing,
which was really a good thing to start with.
But it wasn't the only thing in 6.20, because we got some improvements on Kotlin native
and we got all the improvements that, as an engineer, you can dream of.
So runtime, compile time and code size.
It was an interesting update that brought many improvements on the developer experience, which was really nice.
But the very big thing came later in 1.7.20, which was finally the new memory manager for Kotlin.
With that version, it's now enabled by default and basically it's again a huge win in terms of developer experience
because a lot of change changed and we got better stuff.
That's because the memory manager changed from reference counting garbage collection to tracing garbage collection
because in the past it was just made it quick and dirty.
Let's put it in a way to just get out, but now that things are getting bigger and people are using it,
they realize that some stuff was not the best choice afterwards.
So what this means in reality is that there are no more restrictions on sharing objects between threads.
There are more leak-free primitives, which means no leaks on the internals,
but maybe leaks on stuff that you wrote because we can introduce bad things,
but at least the tooling is not sneaking leaks.
What does it mean at the end of the day for developers?
It means that no more freezing.
Finally, we get all the beautiful sun because we don't need to freeze objects anymore.
We are really free to use everything and you just don't have to think anymore on free stuff
and to understand that it's not crashing, that there's no mobility and stuff, so all magic now.
This thing enables a bigger thing, which is the finally cutting-mode platform mobile,
the mobile part, to reach the beta version, which is a huge milestone.
This means that the technology is basically done and it is safe to use in your project.
The fact that it's in beta means that there's still some work to do mostly on the toolchain,
but in the general thinking you can use it safely.
Maybe there will be some cut-out corners on setting up the toolchain, stuff like that,
but don't worry, you can start using and learning your project and do it because it's fun.
All right, now let's move to more close to today and with the recent release of Kotlin 1.8,
we got a lot more interesting stuff in the field of Objective-C as with interoperability,
which is something that people always ask because it could be better sometimes.
With this release, we got some nice annotations like Objective-C name
that let us specify a more idiomatic or more beautiful naming for some function
that we want to expose to Swift so we can just change the name without changing the Kotlin object itself.
Another one is hidden from Objective-C, which as the name suggests, we can hide some function from Objective-C
because maybe we want to have a duplicated function that works better
or has a better representation for the Swift word and we want to just hide the Kotlin one
so we can save precious binary size and have a specific function only for the iOS part.
Finally, another interesting thing is the should refine in Swift annotation,
which basically tells the compiler to mark a function or a property as a Swift private.
Basically, it's going to be exported on Objective-C with a double underscore
and so with a double underscore, this function will be invisible because autosuggestion doesn't autosuggest.
On iOS, sometimes stuff are invisible because autosuggestion doesn't work properly in Xcode,
but that's another thing.
But in this way, it will be possible to hide some function and then rewrite it on Swift
to have a better idiomatic Swift way of doing things.
Another experimental thing that we got on Kotlin 1.8 is something that I was dreaming of
because every time I saw, I see Android test and Android Android test, my ads explode
because every time I think that it's a typo or something, but it's not a typo.
But right now, this will change and there will be more descriptive things
like instead of Android test, Android unit test, and instead of Android Android test,
Android instrumented test.
So it's going to be more clear and you got to understand really what is this thing.
Connected to that, there will be more clarity also to where to put the manifest.
So not in the Android main, but you're going to have a specific folder for the bug and release version,
so it's going to be more clear just and you got to understand better.
This thing is still experimental, of course.
It's going to be enabled by default sometimes in the future,
but if you want to use it, you have to opt in with a Gradle option.
Another thing that there was in Kotlin 1.8 was the stabilization of the Kotlin.js
and so finally, right now, all the three different technologies, so Kotlin for the JVM,
Kotlin native and Kotlin.js are using the same backend, which means better handling, less bug,
and everything works better.
Another interesting goodie that is not specific to a specific version is that
since version 1.4 to 1.8, they were experimentally checking binary back to work compatibility,
which is always a nice thing.
And from now on, there are processes set up on the side to keep binary compatibility from every release,
which is going to alleviate the pain of having stuff broken.
All right, another very interesting thing about Kotlin and the multi-platform word
is the fact that JetBrains is maintaining also a composed version for desktop and the web,
which is a fork from the Android one from Google.
And yeah, the support is going on, but it's really neat.
It's really beautiful because you can just use something nicer to write a desktop application
and not still have not to deal with Zwing, Java, whatever stuff.
So it's really nice that we have some sort of things.
Of course, it takes time to keep it up with Google releases because they have to catch it up.
But for example, a couple of days ago, we got the 1.3.0 release,
and some stuff is going forward also on this side.
Last year, we got also some interesting experimental stuff which is composed for iOS.
Yes, it seems happening.
It's still some very experimental and technical preview, so absolutely not ready for production.
But people in the community are playing with that.
For example, folks touch up, they built the DroidCon app for the iOS version of the DroidCon app
with compose for iOS, which is something amazing.
And yeah, this is something, as I said, not ready, but it's something to keep an eye on
because it's going to be wild and interesting.
So what is going to come this year?
Well, there will be more improvements on the memory manager,
even though it's already stable and it's the default memory manager.
So folks would keep increasing and fixing bugs and increasing performance on that.
Of course, there will be more improvement on compilation time on Kotlin native
because it's still sometimes not the fastest thing in the world,
and so it has to be improved.
Another point, which is, like I was mentioning before, it's always asked from people,
is better exporting to Objective-C, so have better APIs to interact with from the iOS part.
And also, another thing will be after confirming that there are tools in place
to have backward binary compatibility for the Kotlin native version,
they will describe and add more improvements and documentation for library developers
to maintain a binary compatibility as well.
All of that is going to...
All of these improvements are connected to have finally Kotlin native platform mobile to stable,
which hopefully is going to happen this year.
And in order to do that, there are a bunch of things that need to be addressed.
Like I said before, it's mostly tool chain and infrastructure stuff,
but the main thing is working and you can start already using it because it's in beta
and stuff are kind of working right now.
With that was it, the introduction of the journey into Kotlin for this year,
from the past year and for this year.
So, thank you very much. There will be a lot of content today,
so feel free to catch it up with all of that and have fun.
Thank you very much.
We do have four minutes for questions, so if you have any, raise your hand.
We'll bring in the microphone.
Is it okay if I ask three consecutive questions, two of which are related?
First of all, in terms of Kotlin JS and Kotlin native,
those are not intended to be a performance alternative for existing solutions.
Kotlin JS wasn't meant to be a challenger to TypeScript,
and Kotlin native wasn't intended to rival things like Rust or Go, etc.
Is there a change in that ambition?
That's my first question.
My second question is, does JetBrains have any plans to use Compose
to port their IDEs to Compose from AWT?
Okay, for the first one,
I'm not sure if I heard or read some changes or stuff,
but yeah, there's just another thing in the ecosystem,
probably it's not gonna replace.
I'm not sure what you catch or what not, so I'm gonna restart.
I haven't read stuff or heard stuff that changed what you were saying.
Probably there's gonna be other tooling to support and not to replace.
So it's gonna be another thing to cover and other use cases,
not to completely replace.
But yeah, I don't have more clear guidance or evidence or opinions about that.
The second one was about, there was noisy, I didn't get it fully, but...
Yeah, I'm not JetBrains, so I don't know,
but probably yes, if I have to bet it.
I know that they have their own runtime for UI and stuff like that,
but probably yes they are gonna use it, but I'm not JetBrains, so I don't know.