 Today we will talk about present and future of Kotlin wasm. My name is Zalim. I've been working on Kotlin in JetBrains for quite a while. I think more than 10 years. Now I'm leading the team behind Kotlin wasm to chain. So I'm wondering how many of you now about JetBrains heard about JetBrains before? Oh, almost everyone. So okay, I don't need probably this slide. JetBrains IDs to chain at Kotlin, of course. So what is Kotlin? Any idea? Sorry? Better Java? Better Java? Yeah, good option. I like it. Any other ideas? Actually, there is Kotlin IceHunt, there is Kotlin K-Chopper in Poland. But today we will talk about Kotlin programming language. It's programming language developed by JetBrains. It's probably based now for its built-in now safety, which turns the billion-dollar mistake now references into compile time check. It's statically typed language. It also uses automatic memory management. It manages to be both concise and expressive at the same time. Kotlin has multiple compilation targets. There is JVM, native, JavaScript, WebAssembly, JVM backend, you'll widely use on server side and on Android for native platforms. You can compile to very different platforms like iOS, Linux, and so on. And JavaScript at WebAssembly, it's easy. So you can share easily the code between all these platforms. When you need to, you can write code specific for your platforms. In other cases, you just share one code between all platforms. I personally love how Kotlin is pragmatic and also very, very is a lot of fun in Kotlin. Kotlin is more than language. It's a big ecosystem, actually. First of all, it is a big and friendly community. There are a bunch of tools like IDE, build tools, and so on. There are libraries both developed by JetBrains and by community. There is Kotlin Foundation providing financial support to Kotlin ecosystem projects. Also, the Foundation controls incompatibility changes in the language and preserves the Kotlin through the marks. Few months ago, we announced Kotlin Wasm as a new experimental target. We built the new compiler from scratch and targeting the next goals. We want to have fast compilation because we think it's important to have under the second round trip and to achieve that we generate binaries directly and later we're going to make it incremental. We don't do much optimizations during development builds, but we use binarian to optimize release builds. Yeah, we have separate development builds and separate release builds. We want to have a good integration with hosts, for example, to avoid leaks with cross-model linkings. We think having convenient and fast interrupt with hosts is essential. For example, we provide out-of-the-box declarations for many browser APIs so you can easily work with DOM API, with any browser API. And we want to have a small libraries. Freaker or byte is size of Wasm binary for this example. Modern Shiny proposals help us a lot to achieve the most of our goals by using next proposals. Exception handling proposal, as you guess this proposal introduces something like exceptions and a way to throw and catch them. Obviously we use this proposal to support exceptions in Kotlin. This proposal in phase three from four, but actually this exception handling proposal is kind of exception for Wasm process and it's turned on by default in all major browsers. Yeah, usually browsers turn on proposals only on phase four, but yeah, exception is exception. Extended name section, next one. It introduces dedicated section for storing names for entities what could be, have names in text presentation of WebAssembly. It helps to improve debug experience to get more readable text traces to get to see a name of variables or vocals while you debug. It doesn't change anything in term of semantics. So it's easily turned on in all virtual machines. So it just work. Next one is typed function references. It added better typing for function references. Also it add few new instructions which allow to call functions by reference. It is in phase three from four. And to us, but not least, is garbage collection proposal. Interestingly, the proposal itself doesn't say much about garbage collection. There is, I think, one sentence mentioning garbage collection and that's it. But this proposal introduces high-level concepts like structures, fields, references, and so on. This new concept in WebAssembly is very useful for languages and during times with GCA. And proposal is in phase three. We use last two proposals to map Kotlin objects, Kotlin object model to WebAssembly model. Thanks to these proposals, we don't need to bring to WebAssembly own memory manager. So it helps a lot. It's good for final users in term of binary size. Also it's nice in term of runtime performance. As you can see, we use some unfinished proposals, specifically last two. So these proposals turned off by default and you need to do some specifics at the top or inside your browser right now to use Kotlin wasm binaries. What exactly you need to do? I think Chrome has the best support for wasm-gc itself so far and also Chrome provides easier way to set up. You can open the link and register for origin trail for wasm-gc inside Chrome. So you'll get a token. You use this token on your site, on specific page, and you can turn this way, you can turn on wasm-gc support for this specific page and when user come to your page with Chrome, it just work. User don't know anything what you use. WebAssembly where you use experimental wasm-gc there, it just work, it is nice. Next is Chromium-based browsers like Edge, Brave, and so on. A lot of browsers actually, now they use Chromium Underhood. So for these browsers, users have final users have to turn on wasm-gc manually. They need to open ChromeFlex page and turn on it. Next is Firefox, yeah, Firefox users as well have to turn on wasm-gc manually to do very open about config page, find them, wasm-gc and turn on it. Yeah, right, it is, it's not convenient now, that's right, but unfortunately it's the price of using experimental technologies. But I have the great news, next week, actually, on Tuesday, next week there will be vote for moving type function reference and gc proposal to phase four. So crossing fingers, after moving to phase four, likely all browsers turn on their proposal by default and it will be super nice. So how to try Kotlin wasm today? The easiest way to try Kotlin wasm is to try it in action is using our online pre-ground. You can open this link and you get online editor where you can compile your wasm code and write, it will be run right inside your browser. Thanks to origin trail in Chrome, it works out of a box. You don't need to do anything, but if you use other browsers, you need to go to settings and configure turn on wasm-gc support. So actually it's a bit more than just pre-ground. It's component what could be embedded to you on your site for documentation, for tutorials. Moreover, you can create on pre-ground on top of this. Yeah, you can do different things. What else? A student company, we think it's important having great ID support out of the box. So it's not only about editing code, but we believe things like refactoring, navigation, running tests, debugging, and many other things are essential nowadays. And thanks to predefined browser APIs, you get code completion out of the box for Kotlin wasm as well. It's easy to discover APIs with completion. Also, it helps quickly get feedback when you, for example, make a typo. You also can run tests and get results right in your IDE. We generate the bug information in custom name section so you can see original function names in stack traces instead of function name like wasm function one, two, three. Of course, there is things to improve. For example, in stack trace actually there is a path and it's a bit strange. Ideally, I'd like to have a link to original source and I want to be able to just click on this link to open related fragment of code. It is how usually it works for other languages in our IDs. So we want to have the same things for Kotlin wasm as well. How about libraries? We're working closely with library offers to get Kotlin wasm support here. And yeah, here is some of them. Of course, there is a bunch of Kotlin X libraries developed by JetBrains. There is like coroutines for, I think, things, civilization, IO, daytime. There is a library caterer. It is a library to create client server applications. Oki.io, another library for IO. Corgi, multi-platform game engine. Compose multi-platform, Coazum. So let's talk about compose multi-platform. It is Jetpack Compose to create a UI toolkit in Kotlin developed by Google for Android. Some time ago, a team in JetBrains took it and make it multi-platform and it allow writing and share UI between Android, desktop, iOS, and web. And on the web, it actually uses Kotlin wasm. It's a demo, originally built for Android, but right now it run inside the browser. You can follow the link on the top and play with live demo. It works smoothly and show higher frame rates. So, looks good. Also, you can debug on top of original Kotlin sources. You can put breakpoint. You can see costec. You can see workable variables. You can inspect objects. Yeah, as you can see, many things already works in terms of debugging, but there is some room for improvements. Specifically, we are working on improving stepping over lines while debugging. Right now, it shows objects as wasm structures. We want to have a more readable representation by default like showing text for strings instead of internal structure with array of bytes or we want to have better representation for collections like list or maps. Yeah. Next thing, what we want to improve is inspection costec. We want to have better names. There is idea to have some filtering high data. Internal decorations, yeah. What if we had a composed support inside our playground? So, you can easily prototype and share compose UI right inside your browser. It sounds nice, isn't it? Maybe someday we will do it, no promise, but I like this idea actually. So, what about bind of the browsers? WebAssembly is great technology and it's not limited by browsers. You know, use cases for outside of a browser. There is a lot of use cases. There is a lot of projects trying using WebAssembly outside of browsers and we actually think it has a big potential on server side specifically. We've, for example, we've lambda-wide cases, kind of workers, edge computing, and so on. So, it seems to me like Wasm is really used outside of browser without YZ. Starting from 1920, we will provide a built-in support for YZ. Right now we are using YZ preview one. Yeah, I remind you what we depends on GC and exception handling support in VMs. So, you can run right now this code inside Node.js and thena, but stand on VMs like Wasm Edge, Wasm Time, and VAMR are working on GC support as well. Stay tuned. So, as next steps for Wasi things, we are going to switch to preview two and working on component model. Our super early adopter, Sebastian Delos, started experimenting with Kotlin Wasm outside of browser even before Wasi support come. And he started this project called Wasm as side project. The goal of the project is exploring server side and full stack development capabilities with Kotlin and WebAssembly. Combined with capability-based security and microseconds instantiation time, it's going to be a game changer, I think. So, give Kotlin Wasm a try, go to Kotlin in slash Wasm. You can find the required references, links, and so on. You can find me in social networks by my last name. Don't hesitate to ask me anything about both Kotlin and WebAssembly to gather Kotlin Wasm or separately if you're trying to implement something for WebAssembly, VASMGC, I'm happy to help. At the end of session, feel free to come here and grab some stickers or pins with Kodi. And that's it, thank you for your time. Now I'm happy to answer questions. We have a few times, I think 10 minutes. Thank you, any question? What is state of WasmGC in Safari? There is some work in JavaScript core is engine inside Safari. There is some work on WasmGC, many things already done, I think, kind of 80% of tasks is done. There is some bugs yet. If we speak about running Kotlin Wasm inside JavaScript core, I try it time to time. Every time we close closer and closer to finish. I hope in a few months we will get full support in Safari as well. Specific in JavaScript core, I don't know. I don't have any insight about it. I just working on their issue tracker and commits in repository. It's everything open. So in my understanding, in a few months we get some full support in JS core. Vase question, when is JS core come to Safari? I don't know. Question is, is it compilation from source code or from byte code to WebAssembly? In Kotlin, for all backends we have, we compile from sources and from our special library format, klibs. We don't compile Java byte code to WebAssembly. It is two option Kotlin sources or klibs, it's format of fibers. So every backend, it goes in Kotlin Wasm. Yeah, going this way. Could you repeat? Yeah, the question is, if I take some Java libraries put it to my Kotlin project, can I compile it to WebAssembly? Yeah, the short answer is no. With this technology, no. Because if you want to target JVM, you can take JVM libraries and JVM library jars and compile it to JVM. If you want to compile to WebAssembly with Kotlin Wasm, with Kotlin multi-platform, you need to library specifically develop for this purpose with Kotlin multi-platform support with support required targets. It is how it works in this case. There is another compiler, another two chains, what takes Java byte code and able to compile to WebAssembly. As I know, most of them don't use Wasm GC, they just target in Wasm core. It has its own advantages and disadvantages. Yeah, there is another project developed by Google J2CL, but again, this compiler is from Java sources to WebAssembly. Any other questions? One, two, please. What was part, could you repeat? Okay, it's a question about experience of using Wasm GC and suggestions to other languages. It's a very wide, wide question. In terms of experience, I'd say it's quite well. It's good. There is some things that work not so great. I mean, right now, there is structure typing inside, so you can't do easily separate compilation in terms of suggestions. I know, I need to think about it a bit more. Yes, simplest way is actually taking languages already compiled to WebAssembly using Wasm GC, for example, Kotlin, Java, Dart, and working on feature by feature like how if your language has virtual dispatch, just look how these languages implemented, you can get some insights there. Probably it's the best direction, the best way to implement these things. We actually, yeah, speaking about virtual calls, we tried different ways to implement it, and finally we use for virtual methods structures with immutable states. For interfaces, we have two wires, for example. First wire, we have structure with micro-virtual tables for each interfaces, so you first go to this structure with links to an overview table, anything else? Okay, thank you everyone.