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.