Hello, everyone. I guess we are starting because we've been told that we are strict on time, minutes to minutes. So I cannot do anything, but I have to start talking now. And thanks a lot 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 yeah, I'm Kotlin GDE based in Berlin. I'm Italian. And yeah, and today I'm here talking about Kotlin.

Same here. I'm Sergei. 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.

It's 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. So yeah, and generative AI make a thing that probably the speaking these days will be an easy job.

So last year, preparing for the FOSDEM talk, I've been writing my videos about 3 AM before the deadline. So 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 asked 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 surveys 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 their end of 2022 survey.

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 back-end development, which is rising. And like 40% of all Kotlin engineers

are working with back-ends. I must admit that at the end of 2022, the majority of population is still in mobile. The back-end is rising and back-end is trending up.

I was under impression a year ago that, hey, Android is probably the only platform for Kotlin. However, I was 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 back-ends. But today, let's try to avoid getting too deep into particular Kotlin platforms and focus more on 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 most 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. And 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 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. 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 multi-platform.

How to run Kotlin multi-platforms 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 are interested what is 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. K2 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 plug-ins 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.

And the second part is the IntelliJ-based plug-in. 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. Either it's a language server or the index you have locally, your compiler performance really impacts 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 plug-ins. 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. So currently, you don't have a stable, and you don't have basically a documented API for the compiler. So for example, if you're creating a library that changes something, every major or any even minor release of Kotlin,

you need to upgrade it and evolve and maintain the compatibility of the version for the compiler.

Please get back. Yes, it's back. So currently, K2 is in alpha. But as far as we understand, 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 at least 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. And 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. So there is a need for improvement

in various plugins like Kotlin annotation processor, serializable, KSP, and others. And it will take time. As of yesterday, there is a well-done support for KotlinX 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.7.21,

but I'm not quite sure. So unfortunately, KAPT is still not working. So you cannot do any of the annotation processing yet. And KSP, the symbol processing, the future of annotation processing for Kotlin also doesn't work.

But 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. So 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 a current version now. I try to understand what doesn't work right now. And it's 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. And I tried to get deeper and saw that there is a Kotlin version introduced that has symbols

both 2 and 0. I probably don't want to make any judgment here what the version would be. But something suggests 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. And the testing infra 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 pull request getting this support, at least partially. But who knows? This probably will take another six to eight months.

And finally, the IDE support for K2. So as far as I understand, the plan is to create the K2-based IDE plug-in that will probably

start from a quite lightweight one that will support only a few things. It should have the performance that it started to be. Everything worked fast and correct and likely stable.

The IDE plug-in will have less. A lower number of features will be lightweight and will be released likely after the beta or stable of the compiler. So it's not earlier than Kotlin 1.9, probably even later.

So as stated currently, it should have all the code highlighting. It should have basic code completion, like nice and fancy, probably just the stuff you use on a regular basis, but not

for major refactorings or anything else. In debugger, there should be breakpoints and some simple stuff, really, 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. So this new lightweight plug-in is aiming to have the full-featured Kotlin multiplatform support as well. And yeah.

That's my third. All right. So now, after some K2 magic, let's try to check what went through this year of Kotlin Multi Platform and what will come in the future.

So let's start our journey from Kotlin 1.6.20. And the first magic things, beautiful things that we saw, was the hierarchical structure becoming default. And this thing was such a blast, because you finally don't need any more

to do some weird magic stuff, like symbolic links and things, to cover multiple architecture, like iOS version and Intel version and X64 version. So 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 improvement that, as an engineer,

you can dream of. So runtime, compile time, and code size. So it was an interesting update that brought many, 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 Native. And 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.

So that's because the memory manager changed from reference counting, garbage collection, to tracing garbage collection, because in the past, it 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 yeah, you just don't have to think anymore to freeze stuff and to understand that it's not crashing, that there's no more stability and stuff. So all magic now. And this thing enabled a bigger thing,

which is finally Kotlin Music Platform mobile, the mobile part, to reach the beta version, which is a huge milestone. And 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 tool chain, but in the general thinking, you can use it safely.

Maybe there will be some cut corners on setting up the tool chain and stuff like that, but don't worry. You can start using learning your project and do it, because it's fun. So yeah, do it. 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 and Zwift interoperability, which is something that people always ask,

because it could be better sometimes. So with this release, we got some nice annotation, like Objective-C name, that let us specify a more idiomatic or more beautiful

naming for some function that we want to expose to Zwift. 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 an applicated function that works better or has a better representation for the Zwift 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. And finally, another interesting thing is the should refine in Zwift annotation, which basically

is tells the compiler to mark a function or a property as Zwift private. So 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 auto-suggest doesn't auto-suggest.

On iOS, sometimes stuff are invisible, because auto-suggest doesn't work properly in Xcode, but that's another thing. But in this way, it would be possible to hide some function

and then write it on Zwift to have a better, idiomatic Zwift way of doing things. All right, another experimental thing that we got on Kotlin 1.8 is something that I was dreaming of,

because every time I see Android test and Android Android test, my heads 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've 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 the release version.

So it's going to be more clear, and you've 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 ER backend. And so finally, right now, all the three

different technologies, so Kotlin for the JVM, Kotlin native account 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 backward compatibility,

which is always a nice thing. And from now on, there are processes set it up on JetBrains' side to keep binary compatibility from every release, which is going to alleviate the pain of having stuff broken.

Another very interesting thing about Kotlin and the multiplatform world is the fact that JetBrains is maintaining also a composed version for desktop and the web, which

is a fork from the Android 1 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 swing, 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 yeah, and so 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 at TouchLab, they built the Drawicon app for the iOS version of the Drawicon 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 still

is already stable and it's the default way of the default memory manager. So folks at JVMing 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 developer to maintain a binary compatibility as well. All of that is going to, all these improvements

are connected to have, finally, Kotlin Multiplatform mobile to stable, which hopefully is going to happen this year. And in order to do that, there are a bunch of things that needs 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 up with all of that and have fun.

We thank you very much. We do have four minutes for questions. So if you have any, raise your hand. I will bring you the microphone.

Is it OK if I ask three consecutive questions, two of which are related? Yeah. First of all, in terms of KotlinJS and Kotlin Native,

those are respectively not, as far as I understood, not intended to be like a performant alternative for existing solutions. Like KotlinJS wasn't meant to be a challenger to TypeScript, what I heard somewhere. And Kotlin Native wasn't really intended to rival things like Rust or Go, et cetera.

Is there a change in that ambition? That's my first question. And my second question is, does JetBrains have any plans to use Compose to port their IDEs to Compose from AWT?

OK. 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 going to replace stuff like that. I'm not sure what you catch or whatnot, so I'm going to restart.

I haven't read stuff or heard stuff that changed what you were saying. Probably there's going to be other tooling to the, it's another technology to support and not to replace.

So it's going to be another thing to cover other use cases, not to completely replace. But yeah, I don't have more clear guidance or evidence or opinions about that.

And 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 going to use it. But I'm not JetBrains, so I don't know.