KRuMP - Kotlin-Rust-Multiplatform?!
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 542 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/61875 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Computing platformMultiplicationAreaFunction (mathematics)CryptographyTime zoneProduct (business)Android (robot)Operator (mathematics)Computing platformFormal languageLibrary (computing)Cross-platformCore dumpComplex (psychology)Level (video gaming)CodeKeyboard shortcutTwitterMultiplication signParameter (computer programming)Machine learningState of matterFile formatMemory managementRevision controlLink (knot theory)Open sourceSlide ruleInheritance (object-oriented programming)Greatest elementAndroid (robot)Function (mathematics)CryptographyGoodness of fitSoftware bugSoftware testingFunctional (mathematics)Repository (publishing)Software developerComputer animation
07:12
Maxima and minimaOperator (mathematics)Android (robot)BootingGraphic designMilitary operationAdditionMenu (computing)SynchronizationComputer programmingBridging (networking)File formatData structureStack (abstract data type)Category of beingThread (computing)Normal (geometry)Software testingKeyboard shortcutSingle-precision floating-point formatField (computer science)Social classoutputLibrary (computing)Bridging (networking)Serial portWeb-DesignerMultiplication signResultantBitParsingMereologyGoodness of fitLinker (computing)Point (geometry)Complex (psychology)Functional (mathematics)Semiconductor memoryBootingView (database)Endliche ModelltheorieJava appletError messagePlug-in (computing)Direction (geometry)Computer animation
14:19
SynchronizationComputer programmingBridging (networking)File formatAerodynamicsSimilarity (geometry)Term (mathematics)Reduction of orderWage labourLibrary (computing)Macro (computer science)Object-oriented programmingShared memoryQR codeNumbering schemeOnline helpRight angleField (computer science)CurveStack (abstract data type)Formal languageBitProjective planeDifferent (Kate Ryan album)Endliche ModelltheorieAndroid (robot)Semiconductor memoryFreezingSoftware maintenanceError messagePosition operatorSoftware frameworkData managementPlug-in (computing)Local ringComputer animation
16:51
Library (computing)Maize
19:01
Computer animationProgram flowchart
Transcript: English(auto-generated)
00:18
All right, folks, here we go.
00:21
Now on stage we have Matthias Geisler, this guy, and he just mentioned that if you're interested in the slides, we will find a way to share them with you, and I hope to get the other slides as well. Check out our channels for the IntelliJ giveaway on Slack and on Twitter and on
00:40
Mastodon. That's your mic now. Hello, it's the first time I speak with a microphone to be honest, so it's super new to me. However, though, let's speak about Kotlin and Rust. Isn't that a great topic for the day? And how we can write one bug and ship it to as many as platforms as we can.
01:01
I think that it's a very good idea. We should do that. However, though, before we start, just for your sanity, as I said, or as Holger just said, we will provide you the slides. And I also have an example repository. I shared it somehow with you as well. So you don't need to be worried that there's all in it.
01:24
Okay, so what I will speak today about is why should we ever try to put Rust into Kotlin Multiplatform? By the way, are there any Rust developers here? One. Great, the unicorn.
01:40
So why we even want to have Rust in our KMP. How does that look like? What are the cons and the pitfalls? And I can tell you there are many of them. And what are the todos if you want to progress further with the topic. And by the way, this wonderful slide deck is provided by my employer.
02:01
I have to make a short advertisement because they pay the right. I've done that now. Great. Why Rust? Kotlin is great and Multiplatform is great. I hope we all agree on that because we all want only one language to ship our code to all the platforms and maybe a second language is okay, but three is already too much.
02:23
Ideally, we just want to have one. So as I said, Kotlin is great and I really love Kotlin and I do it for a couple of years now, especially Multiplatform. I developed a couple of SDKs and I also have my own mocking library. So check it out. However, though, what's to say about Kotlin?
02:40
There is missing some functionality, which is not super easy to implement. But fortunately, Rust has that obviously already. For example, crypto libraries. That's a big thing or currently there is this ICU package in development, which is dealing with daytime formatting and other good stuff, which you might already stumble upon in Android.
03:01
But to have a Multiplatform version of that is very, very unlikely because the crate itself is developed by the language people themselves. And I didn't see any activity in this regard, for example, for Multiplatform. Anyhow, also, there might be some behavior on Multiplatform libraries you wouldn't
03:24
expect, especially not at core libraries like daytime. If you compare the output of time zones, for example, you will be surprised. Let me call it like that. And if you write some tests and you are thinking they should be the same, I can tell you they are not. So also here, if you run over the case, maybe such functionalities already covered
03:45
in Rust, so you don't have to re-implement the wheel, which is also great. And Kotlin Native itself, if you ever had to write it, it can be really a menace. It just doesn't look great. Yeah, and it's super hard to read sometimes. And it's also, for that reason, super hard to maintain.
04:04
If you have a native language where you can write it on the bottom level, like Rust, it's much better because the code in itself is much more readable. Yeah, and of course, you get out of Rust a much better performance, which you need, for example, if you do machine learning.
04:20
That's also a good argument. So what are the soft arguments? For example, if you speak with some businesses nowadays, startups and so on, you will discover that people are more likely to adopt Rust and Kotlin, which was super surprising for me as well. But I speak with spoken over the last couple months with a lot of people and I
04:43
have no good answer why this is the case, even with KMP around, which is in most cases, I think sufficient. So also another business requirement is that the business itself might want to have the smallest team size possible alone for budget reasons.
05:02
And if you can do it, maybe with two people instead of four people, they will go for the solution with two people, which is maybe backed up by Rust. And one very big argument for Rust is VASM support, which is Kotlin completely lacking right now, which is in the development, I know, but it's far
05:24
from the state what Rust already has. And we have also to think about ourselves as developers. If you might be not aware, last year was a very great year, not only for Kotlin due to the new memory management model, it was also for Rust.
05:44
Rust did a lot of stuff and there was happening a lot of stuff. And 1Password launched their libraries, which are written in Rust. And only a very thin front-end layer is then done on the platforms. And they also have an open source library for that.
06:00
I will provide you with the link later when the slide goes around. So check it out. And the interesting thing is here, they took the Rust layer until the few model. So right until the top. And that's quite impressive with this kind of complexity.
06:20
And what is maybe important for us, or at least for me, I really love the idea of multi-platform, as I already stated, and to drive it further as much as possible, I think that's a good goal. And of course, because we can do it, maybe we should try it out. So how does that look like? Not to scare you, I have just a small portion of code examples.
06:43
What you do on Android and JVM is basically a GNI bindings. You might have seen that. You might already know that, and I bore you with that already. But that is what you have to dealing with that. But the good news here, there is already a very good tooling there for Rust.
07:02
So for example, what you see there. Can you see my mouse here? Yes, this is coming from a crate in Rust from the GNI crate surprise. Which provides you all the wrapping and transferring from Java or JVM into Rust and back.
07:23
Which is super nice to use and easy to use even. So just to be aware of that. So how does that look on the Kotlin side? Something like that. So you have a couple of definitions. In this line, you just load the library. And if you have done it all correctly and somehow ship also the library and your resources with, that is it.
07:45
Then you can use it like a normal library in Kotlin itself. Which is great, I think. So here are some helpers for you. As I already mentioned, there is this GNI crate. There is also an NDK crate for Android, which is also super nice to use.
08:05
So check it out. Flappygain is a generator for bindings in Rust for Kotlin and Java. So I don't like it, to be honest. Because it takes out of much of flexibility, which you might need in some cases.
08:22
Handwritten stuff might be more work intensive, but less error prone. But that's only my opinion. So this native loader is just that you can easily ship the library. And this plugin you will need simply to compile the entire Rust into your Android plugin.
08:42
So how does it look on JavaScript? That's an easy one, because we don't ship it as something we bind directly. We bind it indirectly over VASM. Because as I already mentioned, Rust has a super cool VASM support and has all the crates to back them up.
09:01
So that's on the Rust side, like the other function. And that's on the Kotlin side. That's a little bit more work intensive, because you have to load them asynchronously, which you see here. And that brings a trade off with it, because the entire library or the entire binding has to be asynchronous.
09:22
So you work then with promises and so on. And that can be super annoying, especially if you then go with React and so on. But it works. And it works sufficiently well and surprisingly well. And by the way, this is also a reason why many, many web developers these days are also going for Rust.
09:43
And you have also, as I mentioned, proper tooling for that. You have VASM pack, which does all the hard work for you. NPM is just a bundler. You already know that, perhaps. And you need to have an understanding of promises. That's it. So now we come to native.
10:02
And that's the hardest nut to crack, to be honest. What you have to do, basically, is writing a C binding and a C bridge. Which just means you allocate your stuff on the native side, ship it to the other side in Kotlin, and somehow get your allocated stuff de-allocated.
10:24
This is the most potential for memory leaks, but it works, somehow, surprisingly, sometimes. And also, you will encounter there are many problems, especially with the linker when it comes to iOS. But it works still.
10:41
Not good. So that's the Kotlin side. So as I said, here you see the de-allocation. And this is just the bridging. So you copy the entire string, put it in, get the result back, copy it back, and then you de-allocate. So it's not that much.
11:01
You could possibly even automate it, but it's not nice yet. Maybe there will be something better in the future. Who knows? And also, one key ingredient you have to do is writing a definition file. You might have seen that if you ever had to deal with native Kotlin. And that's also something which can take a lot of time out of you
11:24
because it's also very error-prone, in my experience. Maybe somebody else has better skills than me. I would gladly hear about it. So to do Rust with Kotlin-native, you first of all need some greater skills just to make it all work together.
11:44
You need a lot of patience and a lot of time and good nerves. Because sometimes it's really like that, the one day it works, then you have an update on, let's say, Xcode, and then it doesn't work anymore. And that hits me today because I wrote a backup overnight and I thought maybe it's a good idea, but it wasn't.
12:03
So currently my native part isn't compiling anymore because the linker says simply no. So what are the cons and the pitfalls? First of all, debugging is tricky. You don't want to debug this at all because you have the Kotlin stack and you have the Rust stack.
12:23
So my advice is here, write tests, do TDD. That will take all the heat out of it. So far I tried it, to be honest. And this especially goes if you do a co-concurrency. So if you do something with threads on the Kotlin side,
12:40
if you do something with threads on the Rust side, it gets even harder. So test your code and go even for TDD. It will save you a lot of time and nerves. So Rust is bad with reactive programming, or let's say it doesn't have this pattern yet. Maybe there is something coming up in the future.
13:02
I hope, I would love to see that in Tokyo. But that's something what I was talking about with somebody from 1Password about because that means if you go up to the view model on the top, it's a little bit different to deal with this kind of stuff
13:20
because then you have to write a view model in a way that takes over the whole reactive stuff and so on. And that's also not that nice and can a little bit pollute your entire architecture. So about the z-bridge, I already spoke a little bit, so that's not fun. I spoke about this point in JavaScript and complex data.
13:45
That's also a thing. Do yourself a favor. Just don't try to bind single fields or properties into Rust. Just take your data structure and just make a data class or something, serialize it and then send it to Rust as a string.
14:00
It's much easier. You save a lot of time and also a lot of nerves. And also here a hint, I tried a little bit and also spoke with other people. It's the best approach and the fastest approach is at a current state, JSON. So the Rust JSON parser is really, really fast. And you can...
14:21
Oops. And you can even make via JSON schema sharing this scheme on both platforms. So you still have one definitions and it works on both sides. That's actually nice. So the first one, don't expect help or grievance
14:41
or anything from anybody because that's just a playing field. So I know there are some crazy people out there who are doing that like me and don't know why. Maybe they have no friends like me also. But don't expect any help. And for your own sanity, try to find at least or speak with Rust people.
15:01
They understand the pain. Cotton people, not anymore since the new memory model is here and you don't have freezing errors and something. The learning curve is quite high because you basically learn a new language. And if you ever tried a little bit out Rust, you will know there is a very big valley of pain.
15:22
And yeah, the last one is simply if you know a Kotlin native a little bit, you know that you can't just share if you ship different models via Xcode frameworks or Swift package management. If you have one library, you can't just share them in between.
15:41
You have to build up a monolith. And this also applies for that because it's also static-linked. So it's not nice. So and what are the to-do's? I'm currently working on a plugin just to make it super more convenient. So nobody has to go through the pain I have. I try to make examples. But if you go with that as well,
16:02
if you are interested, reach to me out, go to your local Rust community right on Rust stack. There will be people which are appreciating that and you can educate others, of course. And also the bridging layer maybe could be done in KSP. Who knows? And not only in Rust. That would be nice.
16:20
So just before we come to the questions, two nice projects are looking for maintainers. Please take a photo and scan the QR codes. One of the maintainers is actually here. Tobias, maybe raise your hand. Say hello to the people. And just because they are paying for the trip, my company is hiring.
16:41
So if you want to have an Android position and work with me together, there's a chance. And we have now questions. And I also prepared a high-end demo, you see, that's all written in Compose and that goes over Rust. I have bridged big, big numbers. So you can start with the questions right now.
17:03
I'm just copy-pasting stuff. So let's hope nothing is crushing. It actually crashed, I guess.
17:21
Questions. Can you show me the... Oh, no questions? Oh, come on, guys. I heard that JNI was being replaced for something else.
17:45
I forgot what. There was JNA or something like that, which is... I've done that as well. They're working on something completely new. That's completely new to me. I just worked with JNI because it works sometimes.
18:01
So somebody else, maybe from the Rustian corns. Would you do Kotlin also? No shame on you. Okay, I hope I don't brought you... One is there.
18:21
Yeah, I didn't try that. Please repeat the questions. Okay. I was just asked if I used or know... UNIFFI. I know of the library but didn't use it so far. So maybe later I can report back.
18:45
Seemed I talked you down. Great. That's a good skill. Then we are done. Thank you very much again.
19:02
We're going to have 10, 12 minutes till the next talk start.
Recommendations
Series of 12 media
Series of 15 media