Hi everyone. My name is Patrick Akila. For today's episode, we cover app development with KMP, which is called in Multi platform. We go through the INS and outs of the technology, the adoption patterns within organizations, and what the main benefits are in the 1st place. Joining me today, I have two guests, both friends of the show, Abdullah, dear friend of mine, who's been very enthusiastic about this technology. And ORS, the legend, champion of the returning guests, both
friends of mine. So you can see that in the episode as well. And I just had a real blast, so enjoy. So KMP is Kotlin multi platform. It used to be called when it started KMM because it was mostly for mobile. It started with the idea of sharing business logic without lots of emphasis on UI. So it was mostly you have apps, Android, iOS and you don't want
to replicate code across them. UI is still specific for each one of them, but you would still extract business logic unified in a single source code source, compile it and use it. But then it gained lots of traction afterwards. And then it started being, yeah, expanded. It became KMP. You could then do for much more, many more platforms. You could do, yeah, Mac OS, Windows, you could do web and it was named KMP. Then very lately they introduced even UI stuff.
So it's not anymore only about business logic. Now you could do UI and build the whole thing with a single source of code and then use it for everything. Yeah. And yeah, that's more or less what it is. Interesting. Like when I when I think of app development teams, I've only been a team where we did both variants. So an Android app and an iOS app, but from the same team with something that like cross compiles, but it's not native. Isn't your native something like React Native?
And in organizations, I've also seen teams be separate with regards to those cost bases and those responsibilities. What those kind of duplicate the logic? Because I I'm not aware of that how they would operate in that way. Duplicate the logic You mean In what sense? When it comes to business logic or I'm assuming UI logic as well? Yeah. So in, in general, if you are, if you are an organization that has a team that builds iOS apps or app depends if you are, you have multiple apps or 1.
So if you have a team that does iOS and a team that does Android, you'll end up having code duplicated logic wise, but in each one of these stacks. So you would have Swift code in the iOS team, probably you would have Kotlin or Java code in the Android team, and probably much of that would be doing the exact same thing. It's just that it's a different
platform. Yeah, and organizations have always operated that way because duplicating that logic, especially if it's business logic, seems a bit like something you don't, might not want. Yeah, that's that's this takes us actually to to a discussion that is beyond only mobile. It's it has always been the the philosophical challenge. Shall we have a back end team? Shall we have a front end team? Shall we have Android team?
So after lots of yeah, trials and errors, I think organizations have found out that dividing teams based on product or business is much better than dividing on technology. And that's why you would end up with a team that probably have has Android people, iOS people. And these people would could talk between themselves and either decide to duplicate code or split it out. And this whole thing is independent of of KNP, by the
way. Yeah. What is your take on it, which when it comes to kind of splitting teams with regards to either technologies or stacks versus products? Yeah, I think it's there's no Holy Grail with that. It's the the usual answer. It depends what it definitely sees when you split. Then of course you can go faster as a individual kind of isolated team. But yeah, I don't you missed alignment. There is a saying which says if you want to go fast, then go alone, if you want to go far,
then go together. And I think in the long run, it definitely pays off if you try to align a variety of things. And KMP, as as you already mentioned, has Stephen Deal's potential with that. When you started with a situation where you already have an iOS team and the Android team because, well, the duplicate logic in different layers, right? So you can have logic on the lowest layer network layer. Thus it can actually go up.
So it can be business logic and also even be view models up to the UI with the latest word, which is still alpha, by the way. So the the business logic sharing up to the view models actually mature something which has proven itself in practice. When you then would use the UI layer, it's still alpha. That's still a bit an experimental thing. But when you then kind of are able to share this logic, then well, I think that's kind of evident for kind of benefits you get out of it, right.
So we just write it once and you can use it everywhere. And definitely it comes with an investment in the beginnings, but in the long run you will, yeah, you will be rewarded for it. Do you think in general the industry is is heading towards something like you write it once and you can reuse it more and more because duplicating logic and doing the same thing across multiple teams also creates those communication lines and dependencies.
And I feel like with this for mobile just made sense, I guess. And stuff like React Native has been trying to solve that in a different way. What are we do moving towards that from an industry perspective, you're leveraging knowledge that we have and then executing different things with that. I think so. And the reason why we probably didn't do this before is because we didn't have the tool sets for it.
And that's why I think React Native, Flutter, these kind of platforms became quite popular because just write it once and you can use error. And both of them maybe can discuss and address this later on what the benefits of far of using these platforms are just KMP. I think that's an interesting topic by itself. But when you don't have the tools, well, you don't have a
choice. But now when the tools are there, I think this really opens a great variety of new possibilities which are very, very appealing, I would say. Interesting. When we're looking at an organization that's then that has this separate set up right with either an iOS team and an Android team or even a team that does React Native or Flutter, what would a gradual adoption pattern be for that team specifically? Or if a team has React Native or Flutter, does adopting it even
make sense or? I have a comment about the last point and then I'll answer. Sure, go ahead. Yeah, I I think there is even in the industry a shift in perception about what code is, right. I think for a long time we thought about code as an asset or as a commodity that you would get from developers. Yeah. But I think lately we are starting to look at code more like a liability. And then if you look at code like a liability, you want to
reduce that liability, right? So if you can make sure this is trimmed to the limits, you don't really have it with redundancies in different forms because of different platforms with different people. And these people have different kind of tool sets and experience levels, especially in that tool. So for example, iOS, Android, the more you trim out of this way of working, it's less liability. And then this brings all the obvious things like less
maintenance, less, less bugs. Probably you fix it on in one place, you fix it in all places. But not only that, it also makes if you scale that across multiple teams, it actually makes companies easier to manage and code easier to manage. And then thus your liability is lower, right? And I think that's that's what is making technology companies walk more into that direction. Yeah. But for something to if we, if we go that pattern for technology, they become like that.
I would say existing technologies have an easier way of becoming that, right, Because those are already adopted. It's very hard for new technology to find adoption nowadays unless it's solves something that's new. And if we're going the route of, OK, you leverage whatever knowledge you have when it comes to KMP, for example, if it were to be a different technology, would it still then be as powerful or what's your take on that? I think there were attempts, the ones that was just mentioned.
You have React Native, you have Flutter, but none of them actually could give you the whole image, right? None of them could make you have, for example, a potential single developer that only knows one programming language that could do the whole thing for you, including back end by the way. So you can do back end in Kotlin, you can do everything in Kotlin and late lately with Compose multi platform, you can even do UI, potentially even
front end. So this addresses directly the point of liability, right You you you can have the single language. You don't need to relearn. It's just a tool. Yeah. Why have two seven or eight different tools in your company if you can fix it with one tool? I'm not saying Kotlin is is, yeah, the the word of the Bible that should work for everything. I'm just saying that that justifies lots of them moving towards that direction. Yeah, yeah, I agree with that.
When I look at my own way of working, I like leveraging what knowledge I have to be effective, right? If the technology is a means to an end, I get excited about achieving something, an outcome, and that's not necessarily playing with a new technology. That's more so leveraging technology to do something because that in the end is the goal. But I feel like not everyone is like that, right? People do like to tweak with technologies and do have their preferences when it comes to
their own setup. They always say, OK, if you do a, a project at home, you'll definitely not use what you're using in an enterprise setting because it's you can do it your own way, right? And I get that that's part of the joy. But with this, I feel like you can do a lot of stuff leveraging the knowledge. And indeed, from an organizational standpoint, it's like removing a lot of liability, removing a lot of risk. Hiring becomes easier. So it's also it has that longevity aspect.
I agree with that, yeah. What do you think ORS? Yeah. So I really think this is a very interesting question to ask. So you just asked before if you would do reactive to Flutter, would it make sense to make MP? Yeah, I said this is quite an interesting question which I also don't think has one answer. There are really different answers to to these questions. I think what's important to realise is which strengths does each approach have.
It's not that KMP has all the strengths and the others don't. All of them have a certain set of strengths and depending on the use case you try to solve, well, the strengths is something you can exploit or not. With React Native, for instance, it's JavaScript environment. So if people are very mature with JavaScript, they can get quite far with it.
The runtime performance of a React Native, also the possibilities you have, there are some reps and so on, but you won't definitely get the native experience you would get if you would go yeah, fully native. Same bit with Flutter. So Flutter has an additional hurdle because it's Dart, it's a new language and certain things are not addressed very well. For instance, reactive programming in Dart is quite complicated. So they also have quite a steep
learning curve. You have to Dart VM, for instance, that's something which also gives overhead. It has very flash animation because of this dart. So they are strength there too. So if you if you kind of try to bring something more webby to to a mobile platform, then I think these two choices are quite good. But when you have this use case where really want to kind of leverage the native platform as much as possible and you already
do that. For instance, of course, if you start Greenfield, then you can choose. But if you already do that, which mostly comes in the form that you have an IS team. And if an Android team, that's just the way things are organized, I think then you really can make actually your next step when by using KMP. And having said that, there is definitely organizational kind of price tag to it because maybe not so much for the Android team because they probably going to embrace KMP very quickly.
It's more on the IS side. So do these people kind of embrace or dare to step over settle to use Scotland youth more something TV image and that's really cultural kind of preferencing to a certain degree too. It's not something you can enforce. It is a great tool, so you're going to use it. That the really depends on whether developers are willing to kind of step out of their comfort zone and try something
new. Having said that, as we already realised, in the long run you definitely be rewarded, but to make this first step, that's definitely going to be, well, something that has has impact. And here is where is where KMP have like a magic touch. So every other thing if you are coming probably yeah, lots of apps are native. I would say the complex apps, the majority of them are still native. And if you are coming from that background, which one of these multi platform technologies are
the cheapest to try with? It's not Flutter because it's a new language, it's the whole thing you would build from zero. It's not React Native if you come from native because it's JavaScript. It's not Swift or or Kotlin. KMP will actually be the smallest coast that you could do to experiment with a multi platform technology. And you don't even need to start with the iOS. You can literally ask the Android team, yo, that part of the business logic. I just want to extract it to a
library. Let's try it out. It's set up configuration, some module creation, publishing, and that's it. They they wouldn't learn a new language, they wouldn't need to make a huge refactor, they wouldn't need to do extreme things like learning a new language. It's just extracting some logic. If it's if the architecture and the design of the code is modulized, yeah, it's even much easier.
And then you would try with it and you can test get outcomes and then later you can go to the iOS team, say, yeah, we extracted this part of the business logic. We used it on Android. Let's try a small test for that use case of the app and use this part of KMP. It would be fine. You could you could have outcomes, you could have data and based on that you could decide. Meanwhile, with Flutter, for example, Dart, there is the learning curve to learn Dart.
And then how would you build your existing logic that works in Kotlin or in Swift, in Dart, and then later on maybe generate something out of that and start using it. We're not even talking about building the whole thing in Dart, by the way. For me, Dart makes no sense.
Like I love the gradual, like from a surface level, like I'm not, I'm no expert, but from a surface level, the gradual adoption pattern that you've kind of laid out there, I feel like whatever technology is going to that route, that is something new and already things are established. The only way you get your foot in the door is by having kind of a gradual adoption pattern, right?
Things like Flutter and Dart, if it has that steep learning curve like you described, and then that's the only way you reach adoption, then the only new frontier you have is for Greenfield projects. When they choose a technology and they decide, you know what the hell, we'll go with Dart and Flutter. Maybe they, they have some specifics that I'm not aware of that makes them believe that
that choice is the right choice. But you know, if I stand back and look at the technology landscape, the risk of an organization when it comes to hiring and that specific knowledge, it's a bigger liability than all the other options there. So I. I think timing is an important factor there. It you say Dart doesn't make sense for. Me it doesn't. Make sense? Yeah, I totally understand. If you put it in timeline, it
starts to make sense. So when Dart started, there was no KMP and it was only React Native. And as Earth mentioned, React Native was mostly JavaScript, TypeScript for example. But it doesn't compile to native. It's, it doesn't look, it doesn't feel, it's not a native app, Android or iOS. So when Flutter started and Dart started, it was to address this problem and for a long time it addressed it very nicely. So Dart compiles to native apps, it's not JavaScript being
interpreted inside the app. And and it had, it had a very big ecosystem for years. So lots of libraries actually until today it has much more libraries than KMP. You if you would start a Greenfield project now, for example, and you have people who know Kotlin, people who know Dart, same level of knowledge. I would say probably the Dart people with Flutter would go faster just because of how much is ready and Flutter. Yeah, because at that time.
But the point is how, how, how, how common are Dart or Flutter developers compared to Kotlin in general, right? And that's, that's the trade off that you have now all these apps that are written in native that eventually want to reduce their liability to something more common that already know about Kotlin, because Google adopted Kotlin for Android in like 2017. Would you, would you go with KMP now or would you go with Dart?
And considering the speed that the libraries and the ecosystem of KMP is going, I think it's soon will be as good as Flutter and Dart library and tools wise. Interesting. Isn't Google backing Flutter and Dart specifically as a language and technology? Exactly. But they also have adopted like Kotlin for their Android native. Native. Yeah. Yeah, exactly. That's interesting. Google is in that sense a bit in between, right? They're backing, of course, Kotlin as a language for Android
primary language. It's a long time ago on a char when it's Kotlin. Same time, they also invest heavily in Dart and also the chart chief VM. That's something that Google delivers. So in that sense, they're also a bit in between and recently they also have start adopting KMP for for instance, the Google Workspace, you know, the Google Docs and the like synchronisation mechanism now is built in KMP because this allowed them to write this logic once and use it everywhere.
So not only on mobile, but also on the web platforms, also on the desktop application. So that's something they now see as a clear benefit. And at the same time they compete well with their Dart, of which of course Dart is more for mobile, right? So it's not really AIOS or Android thing or a multi platform thing. It's more these two platforms or it's a working very well. I'm interested if they're going to keep backing both. Basically, yeah and there were some recent rumours whether it's
we'll keep them back or not. I think I said it again depends on whether which use case you try to solve. Maybe it's an interesting to to to look at some figures. I did a bit of homework just to see a bit what kind of usage adoption these different frameworks have. So I figured that Dart Evan has the highest. So about the 46% dumping me down on the exact numbers are have used flutter in that sense, the flutter is is number one.
Then you have rag native as a second and third, then can be kind of the the new kid on the block. Having said that, only about 1/3 of the mobile developers have used a multi platform framework. Yeah. So about 2/3 are still using the native counterparts. And exactly this is as you mentioned, I think the sweet spot for a gradual adoption of KMP. So I also expect the adoption of KMP to be increasing significantly in the in the coming time. Yeah, interesting. I think so.
There is nothing still until today. There is nothing controversial in Google backing both or liking both, right? Because even when, when Flutter and Dart started, it's, it was mostly, it was mostly OK multi platform. You develop one time for for both, but it was very widget based and it's it's also a lot for the UI. Meanwhile, when KMP started, it wasn't about that. It was about business logic.
Now compose multi platform is gaining traction and it is based on Jetpack Compose. So it's it's also Google has a hand in there, even in the front end part. But it's still, I think it's not alpha anymore. I think it's beta. Beta. Not China, at least not not final in that. Sense yeah, so it's still beta. So Google does not even have the pressure to back compose multi platform for the whole thing,
UI, business logic etcetera. And there's nothing wrong with staying with Flutter and backing clutter, but I would say maybe there will be more reasons to decide or to recommend one of these. When compose multi platform becomes stable, there are official releases, etcetera, then this topic might come up. But until then, why not? You like both, you support both and. It's fine. I like the option of kind of, I mean, competition is always good, right?
It allows the other to kind of learn from each other in Excel. I think that's what we've seen with Kotlin and Java mainly. A lot of the things that were solved in Kotlin are now also released the newer version of Java, which makes the language better in the end, which is a good thing with multi platform now as well. I feel like it's similar, but
then the banking is the same. And from a technology standpoint, if we're looking at a feature and I have an experimental mindset, I would love to say, OK, we do a few variants of the feature and we see what sticks. I feel like this is the same but on a bigger scale. And usually that has impact because if all of a sudden the banking stops, even though if it's backed by a company like Google, that would be catastrophic to some degree because then you would force migrations.
Google actually stopped in 2017 and said the official language for us is Scotland now. So like, it's not like they always don't take positions or mention. Like they want to do. So I expect something like that will happen. I don't know when. It's also that Flutter is their baby. Java is not their baby, so you don't know it's. Hard to kill your darling. Yeah, that's for sure.
Yeah. When it comes to the learning curve, we talked about general adoption when it comes to kind of migrating the existing code bases that you have. But if I were to start from scratch, I've only played around with Kotlin for a couple months, not more than that. But when I would start, let's say an app development project and I want to learn KMP, what's the learning curve like? Are you a mobile developer or just add developer? You can you can take any position.
Yeah, if you are a mobile developer and you've then done anything for Android, I think it'll be very easy. Like very easy. Like even not not only sharing the business logic with KMP, even Compose multi platform. Yeah, then your brand new stuff would also be very easy because it's also based on Jetpack Compose.
Yeah. So yeah, I I don't expect lots of of hassle and I think it would be much easier than any other multi platform option that you could pick if you are a developer in general, not a mobile developer. It also depends on what kind of programming languages you have used in the past also. But also, yeah, I don't see it
as a very, very hard thing. I think, I think Jetbrains name is a very good thing to use anything that they have ID ES, programming languages, they're they're very supportive. They're everything they do is very well documented. Their ID ES work like charm with whatever language or platform that that you're using. And that, yeah, for me, it's always a positive sign if there is, yeah, Jetbrains there. Yeah, it makes sense. Yeah.
I would like to add on that that there has actually been a lot of effort in making JPEG compose very similar to for instance, the way you do state management in React. So if you are a VEP developer doing React, it should be fairly easy to do some JPEG compose because the constructs, they look very similar and I know kind of what kind of mechanisms they had to put in place to make that happen.
And they use really a lot of advanced Kotlin to make it feel like React in that sense, for instance, restate management with the function definition and so on. So it's kind of important to mention because they also figured that when someone hops from 1 ecosystem to the other, it shouldn't be kind of a total new world where they are dropped into. So it should be to certainly reach familiar. Even so, it's a different
language, different paradigm. I think they tried that long time ago with Cotland, and they found out if you make it easy for new people, then it's just a matter of time. And Jet, yeah, Jet Prince is just doing this continuously with everything, and it's working really like charm. I like that it's not reinventing the wheel and I'm strategically, I think that's on purpose, right? If you want adoption like we I, I give the example of having a
new technology. It makes sense if you use paradigms that exist in a different technology as well, because then the, the learning curve is smaller. I, I tried to play around with Rust and even though things are similar, the learning curve is quite steep, right? So then I, I got to a level where I was like, yeah, I'm out. I don't feel like I want to go in depth for like a pet beef project. I'll use it when I think it's most apartment and that's really when I'll step it up.
But otherwise it doesn't do anything for me basically. It's been a long while since I looked at at the programming language and I was like, man, this is hard. Rust was the Rust. Was the last one, yeah. Even though we have to add that nowadays with AI, things differently have become much simpler to adopt new languages, especially frameworks. You just get some snippets which really help you to adopt the language much easier than it was maybe 3 years ago. That's something we can state in
general. Yeah, it's not only applicable for KMP, of course, applicable to all kind of languages. So transitioning between 1 axis and two and another. Is doable, yeah. I think with AI, I feel like learning becomes like easier if you have good fundamentals, that the fundamental part will always be crucial. That's why I'm a bit fearful for, let's say, a new generation
of software engineers. They will Start learning with AI, and especially since AI on my YouTube channel now, it asked me, are you OK with having your podcasts and video content be used for AI as a knowledge base? And I haven't decided yet. But if that's the case, then it's like, yeah, how much? Yeah, I don't think I get any money, by the way.
But if that's the case, then it's like, OK, whichever technology makes the most noise, you might also get prevalence when it comes to then AI distributing that knowledge to the people that learn to it. And that can be very destructive. I feel like because we already have companies that I mean, you want to advocate for developers with good intent usually, but not every technology has a
place. I feel like not every technology is like, OK, just because XY and Z people are recommending it means I should use it. But from a human standpoint, that is what's out there. If I can find a certain solution that solves my problem, then I'll look towards that solution because it has solved my problem and I might adopt it. So I'm a bit fearful with regards to that. Learning, I agree. I agree.
When you lack a certain foundation, then you kind of at the mercy of this AI generated code which really can lead you in the wrong direction. So well in the end you still need someone to at least a bit understand things going on. But on the other hand, when you look at history of program languages, we kind of keep levelling up our abstractions, right. You had assembly and then you had all these other layers. Yeah and yeah. Time will tell how this will going to be really think it's an
interesting development. We should kind of yeah on the go and and and focus on consistently because, well, the final answer is not there, but definitely we'll head into a certain direction I assume. Yeah, yeah, I. Feel like that as well, yeah. Yeah, I've had a funny situation with with code and AI. It's with Go, OK. And you know when you have like a Go routine inside the loop and then yeah, you have to pass variables inside it?
Yeah, it's insane. Like ChatGPT would never accept not capturing the variable inside that loop. And this is a common thing that you would do in Go like since forever, but they solved it. Yeah, yeah, you don't have to do it anymore. Yeah, it's like in 120, I think in 20. 232323. 2223, whatever it was solved. You don't need to do that anymore. You can just literally delete the code.
Yeah, and copilot is fighting with me the whole time, every time I write a loop with a go routine and trying to put the capture of variable there. And I imagine if I didn't know, if I didn't really read their release notes, like I would just say, OK, OK, OK. And then you're just adding more liability, more lines of code without any reason. And imagine that on a higher scale, which is what you say, people who who are maybe too comfortable don't go for like
sources of truth. They would rather have it from from AII think there should be some methodology or some way to cross check whatever you get from AI, especially if you are learning, like if you are using it day-to-day, yeah, it's it's less worse. You probably have some good fundamentals. But if you are learning now and you're just eating what is being fed to you from AII think it's a
tricky situation. This also touches on something else you said, which is the the industry and how much money is being invested into. Yeah, into stacks and technologies to just have wider adoption and thus making more
money. And that's something I think Peter Levels also touched on. It's like it's there is a whole big industry in the development, in the development between software engineers that is just about putting lots of money, making you use this technology, this framework or this cloud provider without any clear benefits for you.
It's just marketing, selling you something that you you don't really need or your project wouldn't really need just because it's the hype, it's the new thing or it's the best thing to do that technology with. And this combined with AI that would just feed you and you don't know, wouldn't, wouldn't know what you are being fed. It's a pretty tricky situation. I think just to be clear, I'm not pessimistic about it.
I'm just, I'm just really thinking that there should be a way for new developers to work around that, yeah. I feel like, so if it becomes another extraction layer and we don't see what happens under the hood, then it might not even matter, right? If I understand what happens, if I can achieve an outcome and then in the end it doesn't matter how I get there, then I feel like people will choose that option, right? Because that's what I've seen in
the past. If you get a quick solution, then usually you go for that route and then you can test your outcomes, right? You can be more experimental. You might be able to be more effective maybe when it comes to, let's say, the quality and longevity of the project. Hopefully that abstraction layer can accommodate for it and it will still work if you build on top of it or you build for longevity. How about coasts? What do you mean by how about cost?
Yeah. So OK, you have an abstraction layer it, it solves a certain kind of problem that you have, but I don't see any AI actually giving you a solution that takes into account a lot literally financial cost. For example, if you would use this this framework to put it on, I don't know next JS for example, for front end to give you the code on how to do server side rendering to give you the code on how to do the front end. But cost wise, is it really a
good decision for your project? Do you need that? I'm not sure if AI is doing that now. No, because we don't optimize that. I don't think AI optimizes for you. It's like you said, OK, you might. Companies are selling you now what you might not need necessarily. But I don't think people look at what they need. They look at ease of use.
I think first and foremost that's what developer relations and developer advocacy look at. They make sure that it's easy to set up. The docs are excellent and then they just are out there. They draw comparison. So they found people that are more influential in the space, Youtubers, maybe podcasters, podcasters, not this guy. But in any case, that's how they at least get a hook in, right?
And then once you find adoption, I feel like the the ball just keeps rolling and people look at more so ease of use rather than what they need to use. And there's also actually another angle which probably a bit under underestimated when it comes to AI assistance, which has to do with the fact that AI is good at things. It has a lot of to be indexed
from, right? And especially when you have new frameworks like KMP, like for instance Chappa Compose, which is in better stage, there's not yet a lot of code which supports it. Especially in the beginnings of a new framework, you have quite some breaking changes normally because you need to find the right, right way of abstractions. So AI assisting, SI assistance won't be that helpful in the beginnings. Yeah, especially when you have new technology.
Of course. That's why I think AI was very good at kind of programming language device. But framework advice often is quite tricky depending on how hard a framework evolves. So when it evolves quick, then you probably all had this once in a while that you get some snippets of an old version of the framework. So I'm also that sense not very positive about it for KMP in that sense, especially the new additions to it. AI won't help you there much because, well, it doesn't have
yet the knowledge. Interesting. I feel like people that identify then with a certain technology and especially the technologies that are most out there, those are going to be, I mean, the easier solutions are going to be
solved by AI, right? If I have many examples on how to solve something in JavaScript or Python, then those examples that it's going to spit up is going to be more so out there compared to Rust, the newer technology or newer language with way less examples, especially compared to those
technologies. So then if I as a person kind of identify as a Python developer or a JavaScript developer, then I can leverage those tools or all of a sudden my job might be more so I think emphasize of the complex problems. But even from a technology standpoint, I might need to focus on other technologies to leverage kind of the knowledge that I have and see how that's applicable, right?
If something new as KNP comes out and I don't really know how to pick up a new technology because I identify only with a certain specific one, then it's going to be more challenging for people compared to people that are more comfortable with that, that can actually read the docs and set up something from scratch rather than using an AI assistant that doesn't really know yet about this new framework. I think we've been there before, right.
Like with every new programming language you have. Yeah, a lack of tool set for you to to make you go faster. Yeah. If it's AI assistance or if it's just an IDE, it's it's the same thing, right? A proper IDE makes you go faster. Programming AI assistance that know about the language also
make you go faster. Yeah. At the end of the day, new programming language or new framework or new technology always brings this Yeah, slowing developers down because there is not a lot available either in AI assistance or in any other thing that would make you go faster. Even meet UPS like you wouldn't have a meet up for a language that was born yesterday. Mojo have a meet up in the Netherlands. I don't know.
Fair enough. Yeah. And the good news is of course that KMP is still up at Chat Brains and the tooling support at Chat Brains has really a very high priority level. So in that sense, normally you would also get your IT support right away. So also without any assistance, I think you still can do quite decent adoption of new features and new technologies. I wonder if with with KMP now kind of getting it's it's grounding. It already has a stable release.
Would I recommend then Kotlin as a first language? I don't know actually about that, but you can do a lot with Kotlin. If you learn that specifically from a language and tooling perspective, you can get quite far. I don't know what other language I would kind of advise. JavaScript is definitely out there still. There's many examples of JavaScript, but then it's like, yeah, if you have a lot of history, you also have a lot of baggage with regards to examples
that might be outdated. That's kind of the hard one. Would you recommend Copeland to start off? Are you going to go low level like the? Famous. It depends, right? Yeah, yeah, yeah. I would say we've had this, this discussion before. I think there were many advocates for all TypeScript. I think that was the initiative name doing everything TypeScript. TypeScript you can do back end with node, you can do front end
with reactor next or whatever. You can do React native for mobile, can do even scripts and pipelines and TypeScript. Even describe your cloud in TypeScript. I think it doesn't really matter like, but it really doesn't matter if you go and say you should do Kotlin first or TypeScript first. I think if you pick your case, you'll probably find good arguments for all. Scotland is not the first programming language that can be
used on everything. And yeah, the same way you treated TypeScript. I don't know a couple of years ago you could treat Kotlin now. But I think there are very good reasons for you to use Kotlin. And if you are doing if you have native apps and you are doing multi platform unifying your code base, you should have very good reasons to not do it in KMP. Yeah, exactly. What are your thoughts? Yours.
Yeah, I would definitely emphasize that too from a land perspective has a lot to offer, especially also when it comes to the reactive part, to the streaming part. So these kind of efforts are really very well incorporated in the language. So especially for these advanced use cases, I would say, yeah, it has most to offer.
Of course, that would be typed. So all these type safety you also get and what's probably also something which you haven't re discussed yet, but you actually almost don't get any overhead if you would go down the cotton round. So if your app really needs to perform so, if you are one of the top apps in the world, then one of your safest choices would be Kotlin because that's the difference with KMP compared to React Native and then Flutter. Kotlin doesn't kind of compile
them intermediate format. It really does a native compiler, it compiles native code. When it comes to KMP, the overhead is also really, really small. So I also, I looked it up, it's about per project, one to two Mac. You get extra because you use some KMP flavour of it for the platforms, which is definitely different for all the others. So the diverse 1 is Flutter, I said because it needs to also ship. It's a Flutter VM and React. They have kind of a mix with native Quanter and so on.
But that overhead is about well, 15 to to 20 Meg extra. So with Cotlin you get a very mature language gets job done. But those from a runtime perspective, you're rewarded so well if you dare, then it's definitely the point. Is you don't have to dare too much, right? That's the point. Yeah, well, you know, they're more in a kind of psychological safety fear thing because it's a new thing and general people don't like new things because it's new, right. So that's what I mean with there
in the end. Indeed, once you've stepped over the threshold, you kind of look in the mirror and think, why did I, why did it take me so long? So something I definitely could, yeah. I feel like I'm always fascinated by how technology, how technologies or even open source projects get adoption within a certain organization. I had a person on yesterday yesterday's podcast recording and they had built something open source they did in a different company, and then it got adopted by Airbnb.
Thousand engineers decided to adopt this package, which was like a snapshot testing tool comparable to other examples. But I was like, why? Right. If you look at what was out there, it was backed by maybe
one guy specifically. But apparently we had that level of maturity that this engineering squad 1000 engineers said, OK, at some point probably grew to that level, but they didn't experiment with it. It was successful and then they adopted it in their pipeline and then it grew to that level. I feel like organizations are more aware of what technologies and indeed the risks and kind of liabilities of those, but the power or a lot of power still is in the hands of kind of
developers. Which is why specifically companies with technologies, if you sell a tool, you advocate for developers. So that's where the money then goes. But I, I'm just fascinated by how developers can decide, OK, for the software, even in the longevity sense. We decide to adopt this piece of open source because it's worth it or this specific technology because it's performing in that way and they just go with it.
It's very cool. Like I don't know if there's a different industry where the people that actually do the work and have such influential choices that actually impact the software of a whole organization and tech companies try and kind of mediate for that. Feel like the bigger organization, the more risk management you have. So it's maybe less less apparent there.
But especially in kind of high, fast-paced startups for scale UPS, there's a lot of responsibility and also knowledge and power with regards to being a software engineer and a squad, and you get that autonomy and decision making power, yeah. It's fun. I actually need Amazing, yeah. I think even on developers level like there, there are many good reasons to go that path. Also it's not only company wanting to reduce liability,
reduce bugs or maintenance. Like even as a developer I think my most pleasure comes from building some things for users, right? So you have probably platforms what you write as a code for features and then users using it. If it was for me, I would always focus on building more for these people and not more for these platforms, right. And if I could put most of my time, yeah, improving the features that we are shipping or building new features for the customers or making it more
usable for them. It's much more fun to do than actually spending double the time just because I want to write the code for Android and then write the code for iOS, right? So it's not only liability reduction for the company, or bug reduction or maintenance, it's also fun for developers to think more about the users than about the platform. Yeah, to play devil's advocate, like I've seen people that don't think of the same way as you do.
Like I, I align with that train of thought, but I also have seen people that are like, well, let's use this eccentric language, right? Because it's an opportunity for me to learn something new. They don't think about the impact on the user, the value that it's going to bring for the users, or the impact on the organization.
If those people that love really picking up a new technology and playing around with it get the autonomy and ownership to make those decisions, then that can be quite disastrous. But from their perspective, they're just having fun. Yeah, I think I don't want to go there in that discussion, but there's lots of morals and ethics in that topic. Yeah, yeah, it's a hard one. Like I, I am along the same mindset, right. I like using whatever knowledge I have and being effective with that.
It's it's mainly being go and also now I've I've been hands off for the last year, which is also incredible. And then I think of, OK, how do we bring value or how do you leverage indeed your risk and liability? It's because I'm responsible for the product now and the outcomes there and the responsibility of technology is still with the software engineers there, right. I can't really influence that
from my position. I can give advice, but I also want to have them have the autonomy to make those decisions. Indeed, from an ethical standpoint, if you have people that like more of the eccentric stuff, then you definitely see that to a certain degree. But it can also have like a, yeah, a very negative side
effect I would say. Yeah. And I think one very important parameter in the whole thing is also the amount of autonomy you have, where to mention, I think the large organization to more reach the rules, the less likely you are to experiment with new things because well, then you have to do this Commission ABC, you have to prove it, you have to. So the, the hurdle is much too high. Whereas when you're started, we just need to get stuff done and whatever tool set makes that
happen is the one you choose. So I think it's it's also strong related to what kind of organization you're in. And so we've come back to what they talked in the beginning. Bolt com think they have this, which many companies have this kind of tech radar approach so that certain projects can try out stuff into the tech radar, then you can evaluate it. So they kind of want you to try a new things, but not let it just go headway run loose, but then have kind of a process once
it's been evaluated. But you want to kind of leverage on a larger scale or not. I think that's kind of a common sense approach, especially when you have an organization and also understand they don't want to have this mired of tech just growing without any control. So I can imagine that this is an approach for large transitions, the set for smaller, it's just
get your stuff done. Yeah. And the beautiful thing about KMP is, yeah, we already mentioned it, is that you can't start so small without even having the impact. So the only thing you probably have to change is a bit of your build procedure. That's a build script normally. That's something you don't have to tell your manager. I'm going to change my build, right. You know, not get you don't get admission for that. You just do it.
And as such, so once it's there and you already have your foothold and you've proven that certain things can be done solved in a in a non redundant way, then well, that definitely can be a step. But for more. Good stuff. I love this conversation. I think I have a very good view of what KMP is, kind of the gradual adoption patterns and some of the pros and cons. Before we round off, is there still anything you want to share? Really, it was a fun
conversation. Also I would say too, I think we really touched on everything, the whole ecosystem, the language, the, the, the different kind of tool sets we have, the organizational aspects, the kind of implications choosing one or the other. So in my in my eyes that exactly AI even with AI work came along so. Then it. Really touched on everything. Oh you, you can't do a podcast? Without matching, yeah, maybe. You can use AI to kind of get rid of this actually, right? We can try that.
YouTube would not even suggest to you using the videos for. That's quite funny. All right then let's round it off here. You're the only person, by the way, to have done 3 episodes. I think if I invite Abdullah again in like half a year, then you're on the same level. I'm not going to break this. Record. You're not going to. Invite him again. Good stuff. Then let's round it off here.
Thank you so much for listening. Leave a like if you liked it, let us know in the comments section what you think and otherwise we'll see you on the next one.