Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
Can Kotlin take you everywhere?
1.4k Plays1 year ago
In this episode we're exploring the Kotlin programming language with an expert from Google. What does Kotlin have to offer? Is it just a Java alternative, or has it turned into something much more ambitious? Along the way we manage to discuss Scala, Function Programming vs. Object Orientation, Editors, Higher Kinded Types, Elm, React, UI architectures and multiplatform programming. A very full episode!
Happy Path Programming - Haskell is not as scary as you think: https://pod.link/1531666706/episode/710a605d605fda251f2e83b8858615b8
The Kotlin Programming Language: https://kotlinlang.org/
Android Studio: https://developer.android.com/studio
Kris on Twitter: https://twitter.com/krisajenkins
Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/
Recommended
Transcript
The Evolution and Reach of Kotlin
00:00:00
Speaker
On Developer Voices today, we're going to be looking at another one of those programming languages that all the cool people seem to be talking about these days. It's Kotlin. So if you're a Java programmer or you work on the JVM in some fashion, you probably haven't escaped the buzz about Kotlin. But what I hadn't realized is how much further Kotlin reaches these days. It's not just a JVM language anymore. It's making a really serious attempt to be the one language that you write
00:00:29
Speaker
and then run everywhere so it can take you to the back end and the front end and mobile and even embedded devices. I think that's really appealing right once run everywhere. It's always been appealing if it actually works and if Kotlin is a nice language to write in in the first place. So I've brought in an expert to discuss it. Coming direct from Google we have James Ward. He's a product manager for Kotlin at Google
00:00:58
Speaker
He's a clear fan of the language, and we're going to talk about why he's a fan, what Kotlin has to offer, what's its focus, what's it trying to be as a language? And then, how does this promise of getting you onto every platform actually work in practice? And what happens when it breaks down, when inevitably this attempt to treat all platforms as the same breaks down? Does it have a way of handling that?
00:01:26
Speaker
Well, I've got to say, James has some good answers, some good reasons to believe that it will work. And so we get right down into the weeds about it and kick the tires as much as we can in a podcast format.
00:01:39
Speaker
And just to cap things off, we recorded this podcast just as Google I.O. was happening, so he gives us a sneak peek into the future of Kotlin, where it's trying to go next. So if the promise of writing one thing everywhere all at once appeals, let's get stuck in. I'm your host, Chris Jenkins. This is Developer Voices, and today's voice is James Ward.
00:02:18
Speaker
Joining me today is James Ward.
Kotlin's Role in Android and Google
00:02:20
Speaker
James, how are you today? Good. Thanks for having me, Chris. Great to see you again. Great to have you. I haven't seen you in a little while. So I've brought you in to talk about Kotlin, which I know you could talk about forever. But before we even get there, I've got to ask you about your job title. Yes. Because you are product manager for Kotlin at Google. Kotlin isn't a Google product. So what's that all about?
00:02:48
Speaker
Yeah, so over five years ago, the Android team, I think five years ago, went Kotlin first. And this was really driven by the developer community around Android. They started doing Kotlin kind of on their own. And they're like, hey, this is this is pretty cool. We really like this language.
00:03:08
Speaker
And what if Android made that kind of the default? And so they announced, hey, we're Kotlin first. Java is still supported on Android. But Kotlin is the primary programming language. And so that kind of set off a chain of events, the founding of the Kotlin Foundation with JetBrains and Google. And so yeah, in many ways, Google is now incredibly involved in Kotlin's development.
00:03:36
Speaker
And some of that is driven for Android, but also Google has been using Kotlin on the server side. And so now there's much more interest in how just Google engineering uses Kotlin. And so they're getting more involved as well. That's interesting. Because I always remember Google as being the place that had C, Java, Python, and go away those for the only three. I think they've actually been swayed by users into changing that way.
00:04:06
Speaker
Yeah, I mean, there's so many great language features in Kotlin that help with UI development and make the programming model so much better. And so yeah, I think it makes sense. And the reception from the community has been incredibly positive around using Kotlin for Android. And so yeah, it's cool that this great new modern language has been able to grow kind of organically in the Android community and Google as a whole.
00:04:37
Speaker
So yeah, so I'm product manager for Kotlin, which means that I get to help grow Kotlin on the Android side. But then I also work internally with our engineering teams and their use of Kotlin and doing a lot of things to keep in sync with JetBrands and all the great stuff they're doing around Kotlin.
Rewriting the Kotlin Compiler for Performance
00:04:53
Speaker
And then working on, we have a number of engineers working on the Kotlin compiler itself. There's a big compiler rewrite happening in Kotlin. And so we're working on that. And then Android Studio.
00:05:05
Speaker
will eventually use that new Kotlin compiler, which is faster and better and more integratable and just a better foundation for the future. So yeah, just helping coordinate all that stuff. So you're not too busy. There's a lot going on. And yeah, we just had, we just had Kotlin Conf a month ago and had a bunch of stuff going on there. And then had Google IO this week, a bunch of great Kotlin stuff we talked about there. And so
00:05:29
Speaker
So yeah, just all sorts of good Kotlin stuff happening around Google. Well, we should get to what's new in Kotlin. Maybe we should start with what Kotlin actually is. Do you have an elevator pitch? Yeah, that's a good idea. How would you characterize it in the landscape of languages?
00:05:46
Speaker
Yeah, so I think there's a few things that stand out for me. One is that it's a modern language. It doesn't have the baggage of other language. As languages evolve, it gets harder for them to evolve because they don't want to break a bunch of stuff. There's different approaches to this. As you and I have talked about in the past, I have done a lot of Scala, and I think Scala is a great language.
00:06:09
Speaker
And it continues to evolve at a pretty rapid pace. But one of the challenges with that is like, how do you bring the community of users along with you into those new evolutions? And so Kotlin 3, I think, or sorry, Scala 3 has been out for a couple of years now. And the adoption has been, I think, challenging because there are a number of pieces that have to move along for people to be able to adopt it.
00:06:35
Speaker
potentially make code changes to adopt the new language. They have to get the libraries that they're using, compile their plugins, macros. There's just this giant ecosystem around language, obviously. That's what you want, and the language is a big ecosystem around it. But how do you then evolve the language and bring that whole ecosystem with you? And I'd say that generally, Scala has had some challenges around that.
00:06:59
Speaker
whereas Kotlin being, I think it's like 10 years old now, so relatively speaking for languages, not super old, and so bringing that ecosystem along doesn't maybe have all the challenges that other languages have.
00:07:15
Speaker
And then there is a strong focus on helping the developers and the ecosystem move to new versions. And so I'm trying to think if there's been many breaking changes in the language and library compatibility issues don't seem to be as prevalent in the Kotlin space. So the new compiler that
00:07:38
Speaker
is being worked on, one of the big focuses of that new compiler is for most users to move to the new compiler, they shouldn't have to change anything. And so that's just one way to like, all right, can we replace the whole compiler underneath everyone with something new without them having to really be impacted by that change? And so that's a huge challenge and takes a lot of engineering effort.
00:08:00
Speaker
I'm thinking of Scala 3, which handled that fairly badly, I'm going to say. And Python handled that pretty well going to Python 3, and that was still a lot of work. The transition of Python 3 was, I think, also very challenging. There was a few things that required some significant changes in the ecosystem.
00:08:19
Speaker
The Python 3 transition, from what I know of it, did take quite a lot of effort to get that ecosystem moved. Now it's firmly moved, and that's all great. But Scala 3 has not yet kind of reached that kind of mass migration point yet. And so there's been some challenges there. But I love Scala 3. I'm using it.
00:08:39
Speaker
bunch of projects. And there's a lot of really good language features in there. But yeah, bringing the ecosystem along has been more challenging. But anyways, back to Colin.
Kotlin's Modern Features and Productivity Boost
00:08:50
Speaker
We're allowed to take security on this podcast. Yeah, awesome.
00:08:54
Speaker
So Kotlin has some great language features that lead to better productivity, better reliability, so just things like null safety being built into the language. I think that's becoming an obvious default for programming languages these days.
00:09:11
Speaker
I really hope so. Yes. But that's something that leads to fewer production issues for people that are using it. And then language features, there's a nice DSL style way to use a
00:09:26
Speaker
It's called Lambda with receiver pattern that leads to a nice looking DSL in places where you want to have more of a DSL look to your code, then you can use language features to do that. Things like callbacks, there's a nice syntax for that, which when you're doing UI programming, callback style programming is an important piece. And so, yeah, being able to have kind of language support for that has been useful.
00:09:55
Speaker
case classes to define your data objects has been a feature that people really like. Co-routines is one of the big headline features of Kotlin, which makes the async programming much more straightforward.
00:10:09
Speaker
So, yeah, I think there's a type inference. There's a number of language features that just make it a good, modern, productive language. And then, of course, Colin coming out of JetBrains has a core focus of the language has been around IDE support.
00:10:25
Speaker
And so being able to have great IDE support that is continually evolving with the language has been important. Is that like a double-edged sword, though? Because I know if you, so coming from JetBrains, if you use IntelliJ, it has fantastic IDE support. If you don't, not so much, right? Yeah, I mean, JetBrains' focus is definitely on their tooling. And so the best Kotlin tooling is in IntelliJ on Android Studio.
00:10:53
Speaker
You can use VS Code, and there is LSP for Kotlin, but because it's not core developed by the Kotlin team, yeah, I think that there's some lock-ins there if you want to be in VS Code or a different idea. Any chance of Google taking on the LSP plugin?
00:11:10
Speaker
Google, it's a good question. Because Google is doing a lot of Kotlin development internally, a lot of the engineers at Google are using Kotlin. I think we just hit 15 million lines of Kotlin code in the monorepo at Google, so quite a bit of Kotlin code there. But Google has its own tooling internally that it uses.
00:11:33
Speaker
And for the mono repo in Google, you have to take a bit of a different approach to how you do code intelligence and understanding code. And so for Google's internal uses, the LSP doesn't necessarily make sense. And so I don't know how that future will play out.
00:11:54
Speaker
And then also, JetBrands is a partner in all this. So we want to make sure that JetBrands is successful. They bred his butters by having the IDE of the world-class IDE. Yeah, exactly. So yeah, I'm not sure what the future of that is. I think generally, for a lot of the stuff around Kotlin, there is a focus on growing the ecosystem. And as part of that, there's no reason why third-party developers can't
00:12:20
Speaker
I can't build these tools and use them. And so yeah, I think that as the ecosystem grows, the language support for other IDs will certainly grow. But yeah, in terms of JetBrains and Google, don't know if there will be specific investments into alternative IDs. OK. OK, while I wait for a more up-to-date LSP plugin, you're going to have to persuade me that this language is so great that I should switch to JetBrains or Android Studio.
00:12:50
Speaker
I mean, if you're doing Kotlin, I highly recommend that you use IntelliJ or Android Studio. You're going to have your best experience there. And so yeah, that's a thing. And I'm a longtime IntelliJ fan and user. And so for me, that's not an issue for other people that may be more familiar with other tools. But for me, I love IntelliJ. So I'm happy to be a user at Kotlin. It's nearly as good as Emacs. I'll give you that.
00:13:21
Speaker
Okay, so let's get in some of these copies. I'm a long time VI user, so I don't often edit code in VI anymore. I'm pretty exclusively editing code and intelligent. Yeah, it used to be like this classic war between VI and Emacs, and now we realize we're both basically on the same side against, if that's the word, against the IDEs of this world.
00:13:48
Speaker
Well, you can plug in the LSPs into VIA and Emacs if that's what you would like to do. Yeah, that's why I need Kotlin to get an updated LSP server. Yeah, and it is a community project around the LSP, so hopefully that continues to evolve and the community drives that more. Okay. Persuade me over to this other IDE. Persuade me to the dark side. Let's talk about some of these language features and see what's good about them. So, co-routines, I know you're excited about in Kotlin.
00:14:17
Speaker
Yeah. Yeah. So we often in a UI program or in the server side, you've got something async that you need to deal with. And that's oftentimes related to IO, right? You're firing off, you know, a request to a server and then you don't want to block the thread while you're waiting for that to come back, especially when you're on the UI, you don't want to block the main UI thread because then the user
00:14:41
Speaker
their UI is no longer responsive. You don't want the button to freeze while you do an HTTP request. Exactly. On the server side, it's the most efficient way that you can use your resources in a system that has async calls, IO calls, is to not block those threads. Definitely on the server side, it also is important to be non
Coroutines and Async Programming in Kotlin
00:15:06
Speaker
-blocking.
00:15:07
Speaker
on IO. And so in the world of Kotlin, you can use coroutines to do this. And coroutines give you a, I'm sure many developers now are familiar with async await style syntax where you can basically declare that this thing is async.
00:15:25
Speaker
And then in Kotlin, underneath the covers, that gets unrolled into the right callbacks and non-blocking stuff that you need. But the programming model in Kotlin is nice. If you call something that is a suspend function, then you can, on the next line of code, use the result from what you get back. But underneath the covers, it ends up being actually async.
00:15:49
Speaker
It looks imperative, do this, do this, do this. But then it gets unrolled underneath the covers into the proper async constructs there. And the nice thing about coroutines is that it's a language feature with a supporting library. And so anywhere that Kotlin works, you can use coroutines. So Kotlin coming out of the Java JVM space, certainly you can do this on the JVM.
00:16:16
Speaker
There are some alternatives we can talk about on the JVM that are upcoming Loom. But the nice thing is that places where you maybe don't have that Loom style or Loom capabilities, like on Android, or there's now many other places where you can run Kotlin. You can now run Kotlin on iOS. You can run it on the web.
00:16:37
Speaker
build desktop applications with it, you can build CLIs with it. So any of those places now you can use coveroutines. You get one async construct that works on all the different platforms. So we'll talk about multi-platform in a minute because that's another interesting thing. Oh yeah, we can definitely get onto that. But yeah, the coveroutines, definitely a great programming model for doing async stuff.
00:16:57
Speaker
Yeah, I think now modern languages have, I think, generally embraced that style of programming for doing async stuff in some way or another. So yeah, there's two different sides of coroutines that are interesting. One is the request response style where you're calling an async function and get back the result, but it's async.
00:17:21
Speaker
But then there's the stream-oriented construct as well, where it's called flow and coroutines. And flow gives you the streaming style syntax for being able to operate on something that's not just a single result, but more than one result.
00:17:36
Speaker
And so you get both the stream and the function style approach to async. I mean, the handles both in the same mechanism kind of transparently, you're saying? Yep. Yeah, exactly. Yeah. You do have a different API for the stream construct. So in coroutines, if you call a suspend function, then that's something that produces a single result. If you do want a stream, then you use the flow
00:18:02
Speaker
And with Flow, there's an API where you can emit things into the Flow, or you can then read out of the Flow. And so in the Kafka world, you use a Flow to interact with Kafka. So you get a Flow interface when you're reading from Kafka, or a Flow interface when you're writing in Kafka. And so that's how you then
00:18:23
Speaker
interact with the stream-oriented approaches is through the Flow API. Yeah, it's that difference between grabbing a single row from a database and processing an ongoing stream of stuff. I often think that's quite nice distinction between HTTP and WebSocket, say. Yes, exactly. That's a great way to look at it as a request response or a stream of data.
00:18:51
Speaker
Yeah, and so you can also use a flow for a WebSocket, and WebSocket stuff that I've built definitely will use the interface. And it's great because then you get one programming model for doing any stream-oriented processing. So yeah, whether it's a WebSocket or Kafka or whatever, you use the flow interface for that.
00:19:14
Speaker
Yeah, that's co-routines. Definitely one of the really important valuable features of Kotlin is having that all kind of essentially built into the language. Maybe we should talk just quickly since we've mentioned WebSockets, HTTP and Kafka. What's the library support like? Is it mostly go out to Java or is it like plenty of native support for things?
00:19:37
Speaker
Yeah, so as usual in the JVM ecosystem, there's a lot of different options that you could go with. And so on the HTTP side, all of the major JVM HTTP libraries that are out there now have some Kotlin support in some way. And so Spring and Spring Boot is really the primary one in the JVM space.
00:20:01
Speaker
And so if you are in Spring and you want to do async stuff in Kotlin, you just use suspend functions and flows just like you normally would. And those integrate directly into how Spring then handles the reactive IO underneath the covers. And so, for example, if you want to do a WebSocket, you can just do a flow in Spring and that'll feed the data back. Kotlin does have a Kotlin
00:20:28
Speaker
native, and native is the wrong word, but a Kotlin idiomatic HTTP library called Ktor, and similar to Spring, you can use Kotlin flows and suspend functions, and then all the other JVM, major JVM frameworks have Kotlin support as well and coroutine support. In the traditional JVM libraries, the Kotlin APIs are just wrapping the Java APIs, so there's some
00:20:55
Speaker
translation to what's happening around the covers in Java. But then in Ktor, you can plug in different engines, Netty, or they have their own native HTTP library called CIO. And so you can interchange the actual engine underneath the covers. But your programming model with using coroutines and flows is all the same, no matter what the actual underlining engine is.
00:21:20
Speaker
Yeah, so lots of different options for okay, and then in the world of Kafka
00:21:26
Speaker
I believe that there's now a Kafka, a native implementation of the Kafka protocol in Kotlin. I think that it does not, this particular one I'm thinking of, does not actually wrap the Java API of Kafka. I think they re-implemented it. I might be wrong on that. But from my standpoint, when I'm doing Kotlin with Kafka, I don't have to know or think about the actual underlying protocol handling of that.
00:21:53
Speaker
write my column code just as I normally would with curtains and it all just works. I have to ask myself, is there like a Kafka Streams wrapper that works well? I haven't seen that. It definitely could exist, but yeah, I haven't seen that.
00:22:09
Speaker
Okay, that does lead into my next question. My next two questions, you can tackle these in any order you like, because you've hinted at both of them. FFI and multi-platform, because Kotlin started out as a JVM alternative to Java, right? Yep. So what's the FFI like? And we're not just targeting Java anymore, right? Yeah, this is
Cross-Platform Capabilities and Interoperability
00:22:30
Speaker
great. Yeah. So in the world of Kotlin, you can target multiple platforms, as we mentioned, and JVM was the initial one. And so
00:22:39
Speaker
The interface between Kotlin and Java is bidirectional, works great. So you can interoperate with Java code seamlessly in both directions. And that's been an important focus for Kotlin, is to allow that. There's a lot of mixed Java and Kotlin code bases in Android and on servers. And so having that interoperability has been essential and all works great.
00:23:02
Speaker
Outside of the JVM, the approach has been similar in that Kotlin has made sure that the integration with the native platform works really well. That's the FFI piece. How it actually works is different for each platform, but the goal is to be able to have great interoperability no matter what platform you're on. If you're doing Kotlin for iOS,
00:23:30
Speaker
then that actually compiles down into Objective-C bytecode. And so you're running in process in your iOS app. You're not running in a sub-process. So there are other multi-platform technologies that just essentially VM your app.
00:23:46
Speaker
And so you're running in a sub process and then FFI gets more challenging and because then you have to bridge some way between that kind of sub process to to the main process and it's not a native integration. And so yeah, that gets sticky. Yeah, there's you know performance challenges to that and then there's just like
00:24:08
Speaker
A lot of times you are in a mixed code base, so in the world of iOS, you likely do want to take advantage of a lot of native iOS functionality, and in the world of Kotlin iOS, because it's just Objective-C bytecode, that interop is direct.
00:24:25
Speaker
There's definitely challenges to how it gets implemented because on the Kotlin side, you have to have a garbage collector and be able to manage references across those boundaries and still handle garbage collection correctly. The Kotlin native team is the one that has done all this work.
00:24:43
Speaker
you know, they've made sure that that garbage collector works well on iOS and on other platforms. They have been working on Kotlin Wasm, another interesting multi-platform target, and the Wasm WebAssembly folks
00:24:59
Speaker
just recently added support for Wasm GC, and I think this is still experimental. From what I remember in the latest version of Chrome and other browsers, you still have to enable the Wasm GC support, but Wasm GC allows good plugability and support for the Kotlin garbage collection to happen inside of Wasm.
00:25:21
Speaker
So yeah, but again, the native interop, no matter what platform you're targeting has been a core focus of Kotlin. And Kotlin Multiplatform is the name for all the stuff that is Kotlin beyond the JVM. And so yeah, lots of interesting pieces to how Kotlin targets other platforms.
00:25:41
Speaker
A lot of work under the hood to get it all working. What's it like from a developer's point of view? If I know how to do Kotlin FFI to Java, will I roughly know the right syntax to Objective-C?
00:25:58
Speaker
So it is a little bit trickier in that case because you do need to have some way. So let's say you want to call some native code within Objective-C from your Kotlin code. You do have to generate the stubs, essentially, so that Kotlin then knows about the types that exist on the raw Objective-C side.
00:26:19
Speaker
there's tooling that helps you manage that. But yeah, and then a lot of the core libraries are part of Kotlin Multiplatform. So in the case of Kotlin JS, they've taken the
00:26:35
Speaker
the JavaScript APIs and made them available automatically to you so that when you're in the Kotlin side, you don't have to necessarily write that bridging interop code. It's all just provided in the standard library. Now, if you're doing something custom, then you may have to generate the stubs. Do that native bindings manually, but there's the tooling that exists to help you do that. Same thing with Cinterop.
00:27:04
Speaker
So there's C interop and so you can interop to a native C application as well. Similar that you need to have the Kotlin class that you're calling into and so then your Kotlin code compiles and then gets linked together with your native code in the right way.
00:27:24
Speaker
But yeah, all that exists and is not too challenging. There's a lot of other multi-platform systems that I think are much more challenging for how you do that native interop. But in Kotlin, it's pretty straightforward. There's a lot of people doing it with different platforms. Is it like if you're writing TypeScript and you want to use a JavaScript library that doesn't have type annotations?
00:27:52
Speaker
You've got to kind of come up with your own annotation for the function signatures. Is it a bit like that? Yeah, it's a bit like that. Yeah, exactly. You have to tell Kotlin about what you're calling into essentially. But the nice thing is, is that because all the code's being compiled down to the native platform, that interop isn't through a, you're not having to come up with a socket way to do it or weird FFI system to do it, all just gets linked together.
00:28:18
Speaker
into the native executable. That approach allows for great interoperability, but anytime you do interoperability across languages, you're going to have to do some work to make that machinery all happen so that things can be compiled and linked correctly. I think everyone's expecting some work and the question is how much work are they actually going to come into and how reliable it will be once you've done that work.
00:28:42
Speaker
Yeah, so I think it's going well. We've seen a lot of use of Kotlin on iOS, Kotlin on other platforms. It's been a little bit of use for Kotlin for native applications, and that's the cnromp piece where you want to write a CLI or something that actually is running natively on Linux, Mac, Windows, whatever.
00:29:04
Speaker
And so there are people doing that, not as much as on the iOS side. There is Kotlin.js, which a number of people are using to do web applications with Interop to the JS side. And then Kotlin Wasm coming up as being yet another target where you would want to probably do some type of interop. The Wasm interop story I think is being
00:29:24
Speaker
um, defined right now through, uh, something called, um, the WASM component model. And so they are, the WASM, uh, committees are working on the way to do, uh, interrupt between WASMs and different languages. So it'd be interesting to see how that particular one plays out. Suddenly getting, uh, nightmares of different committees trying to talk to other committees while they're committing their own agenda.
00:29:49
Speaker
Yeah, from the outside, it seems like the Wasm community is evolving very rapidly and working together well, which is kind of surprising for that. There's a lot of different folks kind of involved in Wasm. And from the outside, it seems like that's all going well.
00:30:06
Speaker
and specifications are evolving quickly and with good coordination across different people who have interest in Wasm. So yeah, there's some examples of that. It's rare and pleasing to hear. Yeah, maybe if I was in the depths of all that, maybe there would be a different story. I don't know. We should get some of the Wasm committee on the podcast. Yeah, definitely. You can tell the horror stories.
00:30:33
Speaker
Anyway, interrupt, right? So I'm going to go for a concrete example. If I can imagine then I might write some Kotlin code that did a web server that was also feeding to an Android app, an iOS app, and a JavaScript client. I decide I want to write all four of those in Kotlin with some degree of code sharing.
00:30:57
Speaker
Yes. You know, there'll probably be models, data models among that shared among all of that. Some UI components shared among the three front end stuff like that. Yep. Yeah. Yeah. How painful is managing that? Which code can work where?
00:31:13
Speaker
Oh, great question. Yeah, so what Kotlin had to do around this was they had to create a programming model that allows you to take Kotlin code and be able to target different
Expect/Actual System for Multi-Platform Development
00:31:24
Speaker
platforms. So there's Kotlin code that is 100% able to just the same piece of Kotlin code run everywhere. And that's what we call Kotlin common. So that's Kotlin code that has no dependencies on any particular platform.
00:31:38
Speaker
And so it's 100% portable to anywhere that Kotlin Multiplatform can work. And so there's a lot of energy and things happening in the Kotlin ecosystem to do more Kotlin common, anything that can be Kotlin common, make it Kotlin common, because then it's totally portable across all the platforms. But then there's places where when you're running in the browser, you want to do something different than when you're running on iOS, than when you're running on Android, running on the server, you want to have different functionality across those different platforms.
00:32:07
Speaker
And so the Kotlin team created this system called ExpectActuals. And ExpectActuals are the programming model that you use where you say, in your common code, instead of providing the actual implementation for the different platforms, you say, I expect that each platform will have an implementation of this piece of functionality.
00:32:29
Speaker
And so you do the expect on the common side, and then for each platform, you do the actual side. And so the actual side is where you then provide the platform-specific pieces to that piece of functionality. So in one example, in the browser, you want to use a JavaScript API to modify the DOM, but then on the Android
00:32:57
Speaker
In iOS side, you don't want to modify the DOM because you don't have a DOM. You instead want to talk to a UI toolkit, which Skia is the UI toolkit that is being used as that cross-platform UI toolkit. Skia is an open-source rendering toolkit that actually Android uses to render on Android, but we're able to take Skia
00:33:24
Speaker
and use it on iOS and even use it in the browser with Canvas. And so then you get a consistent API for how you do rendering underneath the covers. And so in that case, maybe you'd say, all right, if I'm running on something that's Skia backed, then I can just have that piece of code be the actual for the platforms that have Skia.
00:33:44
Speaker
But then if I'm on rendering to the DOM, then I'm going to do something different in that path. And so you'd have a different actual for the DOM implementation. OK. OK. Yeah, I can see how that would work. Yeah. Yeah. So from the developer standpoint, I'm still writing Kotlin code for all these pieces, unless there's some
00:34:03
Speaker
thing that doesn't exist in a standard library and a third-party library that's already done the interop FFI piece for me. In all the multi-platform Kotlin code that I've written, I haven't had to deal with the interop directly because there's something that already exists for me, some piece of Kotlin code that is already doing that for me. I'm writing my actuals in Kotlin. I do have to write them for each platform.
00:34:31
Speaker
when there are differences, but I'm still just writing the code there. It just is calling a different API depending on the platform that I'm targeting. I would have thought the challenging part of that is getting the abstraction boundary right.
00:34:45
Speaker
Cause like button is a button is a button, but there are like a table widget has very different properties across the different platforms, right? Yeah. Yeah. So there definitely is always that, that trade off and multi-platform programming as do you try to come up with the common denominator across all the platforms or do you really try to use what is native on the platform? And so, so Dom versus Skia is a good example where the capabilities are not the same across the platforms.
00:35:13
Speaker
And then you do have to decide, do I want to try to come up with some layer that creates that common abstraction? Or do I actually just do the actuals on the platform and decide, all right, on this platform, I'm going to do this, and on this platform, I'm going to do this other thing.
00:35:29
Speaker
And so the nice thing is that the facilities are there to go with whatever approach makes sense for you. And you don't necessarily have to get locked into using a lowest common denominator across all the platforms. You don't have to do that if you don't want to. But you can do that if you choose to. So JetBrains has taken the Compose library, which is the UI library for Android,
00:35:56
Speaker
and they've made Compose work on iOS and on the browser.
00:36:00
Speaker
And so you can just write one single compose UI and then target Android, iOS, desktop, and web all with the same exact UI code. And so if that's what you want, if that's the UI that works for you across all those platforms, then great, you can use that. If you did instead want to have, let's say, just your business logic shared across the platforms, but then to have native UIs, then you could do that as well using the interoperability, the native interoperability.
00:36:29
Speaker
That's pretty because I could see myself wanting to go for lowest common denominator just to launch and then refine it to platform specific for version two. So I could do that for sure. Yeah, exactly. So you can be anywhere on that spectrum and you can move freely across that spectrum. So if you decide, all right, this particular view in my app, I want to be native, then you can just change that one view and not change everything. So, yeah.
00:36:57
Speaker
And then on iOS specifically, you can kind of even embed in both directions. So let's say that you're in a Compose UI and you want to embed a native iOS widget, you can do that, but then you can also embed
00:37:11
Speaker
pieces of the UI being composed back as well. So yeah, lots of different levels of doing the integrations. Okay. This is reminding me of an old promise of Java that would be right once run everywhere. And that never really worked out, right? Yeah. Do you think Kotlin has a shot of achieving that promise?
00:37:32
Speaker
I think that for people that want write-once run anywhere, they can achieve that with Compose Multiplatform. But then there are cases where that doesn't make sense and you do want to be native and you can do that as well. So I think the flexibility of write-once run anywhere or write some of it run once and run anywhere and then have
00:37:55
Speaker
than the native implementations for specific things, you can do that as well. So I think that's really one of the compelling things about Kotlin Multiplatform is that you don't have to buy into everything being one way. You can choose where you want and you can adjust as you evolve along that spectrum in either direction. Okay, okay. It does sound nice, but it sounds like they might have actually got it working.
00:38:19
Speaker
Yeah, I think that this is the first time where I've seen a cross-platform technology that doesn't come with the typical cross-platform trade-offs that often have to be made. I think it is a good evolution in the space that I don't know if I've really seen anyone else
00:38:46
Speaker
Provide that ability to choose where you want to be on that spectrum and move freely. That's pretty cool. That's pretty cool. Okay, let me segue into a different kind of choice between two worlds. Because I know that one of the things about Kotlin is it's using some ideas from object orientation and some from functional programming.
00:39:09
Speaker
Yeah. I find that very interesting, but I'm not sure how well anyone's got the two sets of ideas to sit together in a cohesive whole. Yeah. So which pits has got them picked and how well has it blended them?
00:39:22
Speaker
Yeah, it's just generally with languages. We've seen most OO languages start to bring in functional constructs in some way or another. And that's been a really great language evolution across many different languages. So Kotlin is one of those that has kind of pulled in functional constructs in a variety of ways.
00:39:44
Speaker
It's not Haskell, right? I'm a Haskell fan. I know you love Haskell and I was so glad to have you on my podcast talking about Haskell and learned a lot on that one. Scala has been my primary experience with this hybrid functional approach.
00:40:01
Speaker
And I think that Colin has done a pretty good job of integrating functional concepts in, but it definitely doesn't go as far as Scala or Haskell has gone in that respect.
00:40:16
Speaker
some of the functional constructs and that are important to me in kotlin one is immutability is i wouldn't say a hundred percent default but is much more default than in the world of java and so
00:40:33
Speaker
there is a strong bent in the world of Kotlin towards creating immutable values versus mutable ones. So to me, I'm like, yes, I don't ever want to mutable anything if I don't have to. So being able to easily be immutable and have the language and the library ecosystem really support that paradigm has been good. Then just functions as being a first-class thing, obviously, that's an important piece.
00:41:02
Speaker
If I define a function, I should be able to kind of pass the reference to that around and do functors and all that kind of stuff easily. Definitely well supported in the world of Kotlin. So yeah, I think they're coming from Scala. There are things that I miss in the functional world. So I miss type classes. Scala 3's type classes are really good and definitely
00:41:28
Speaker
the awesome programming model. And so when I'm in the world of Kotlin, I miss things like type classes. I'm trying to think of other functional constructs that I miss. Kotlin doesn't have
00:41:46
Speaker
higher kind of types. Yeah, does not have higher kind of types. Yeah, so it does not have higher kind of types. And so that's something that when people get into Kotlin, they're from Scholar Haskell, they're, God, I miss my higher kind of types. And so, yeah. If any listeners don't know what higher kind of types are, we'll link to the podcast I recorded on your show, Happy Path Programming, where we talk about it extensively.
00:42:11
Speaker
Yes. Yeah. Yeah. So higher kind of types are something the higher kind of types are kind of beyond my realm of brain capacity. Generally, I think that I benefit from them with with good flat maps and all that. But in the world of Scala, but I know that in the world of Kotlin, those smarter people definitely complain about the lack of those and
00:42:36
Speaker
If we step one down, I am assuming Kotlin has generics like Java, right? Yes. Yeah, generics. And then inheritance as well. So coming from the world of Java, you kind of have to support inheritance. And so yeah, it does support inheritance. And
00:42:53
Speaker
And then there's some support for ADTs. So you can do something like a some type with this kind of simulated in the old ways that we did it and Scala with a sealed trait or sealed class. And that allows you to do your exhaustive pattern matching on a some type and that sort of thing. But Scala 3's ADT support is pretty awesome and Kotlin doesn't go that far in terms of their ADT support.
00:43:22
Speaker
It sounds like you're vying to come back on the podcast to talk about Scala 3 at the same time. We'll get you back in six months and we'll cover it. The thing in the Scala ecosystem that I've really enjoyed lately is effect systems.
00:43:43
Speaker
and using Scala.xio for effects. And Kotlin doesn't quite have a way to do effect systems as well as has been done in Scala yet.
Functional Programming Elements in Kotlin
00:43:57
Speaker
There's a new language feature that is experimental called context receivers. And there's a functional programming library in Kotlin called Arrow.
00:44:07
Speaker
And the Arrow folks have been experimenting with doing something kind of similar to an effect system on top of the context receivers, the language feature in Kotlin. So it's some interesting evolution in there. But if you want to do functional programming in Kotlin, Arrow is definitely your go-to for how you do that. For those that don't know, define an effect system.
00:44:31
Speaker
Oh, yeah. So an effect system, for me, is a way to separate out the pure functions, the things that have no side effects, so not talking to the outside world, whether that's the network or even non-obvious things like getting the system clock or getting a random number from the system. Those are side effects.
00:45:01
Speaker
external call. It's not a pure function. I think you can correct me if I'm wrong here, but kind of the definition for me of a pure function is, if I call the function more than once, will it always produce the same result? Is there a direct mapping between inputs and outputs?
00:45:18
Speaker
With effects, we recognize that, hey, it sure would be nice if we could delineate the pieces of our code that are pure from the pieces that have side effects. The effect system gives you a programming model to do that delineation. But then one of the challenges is that when you're in the world of effects, you're no longer working with a pure function. You have some other construct that is modeling that.
00:45:46
Speaker
that side effect that's happening.
00:45:49
Speaker
And so all of the great things that we have in functional programming around function composition, you then need to figure out, OK, how do I compose things that aren't pure functions but are effects? And so and so there's some challenges to to dealing with with the composition of effects. And this is where Scala Zeo has done such a great job of being able to to model the effect parts of an application and make them composable.
00:46:18
Speaker
And so the programming model in Zio, it allows you to do some pretty amazing things, like if you've defined an effect, but then let's say you want to repeat it, or you want to retry it if it fails, or you want to be able to erase two effects, you just get this really nice API for doing those sorts of effect compositions that are not functions, because you're no longer in the realm of pure functions.
00:46:46
Speaker
So yeah, I have been loving effect-oriented programming and programming in that style in Scala. And then testability. So one of the things that you get when you model your effects is that then when you do your tests, you can swap out the side effects for something that is no longer a side effect so that you can more effectively unit test all of your side effecting code without actually doing the normal side effects. So moving from
00:47:12
Speaker
your integration test that would be talking to the live random number generator, which can be problematic in a test. Well, it turns out you can just like in your test, throw in an implementation of the side effecting piece.
00:47:26
Speaker
And then it makes it much more testable. So yeah, that's a fun little tangent on a file system. Yeah, it's a bit like programming everything to an interface and then swapping out the real system for the mock. But just nicer when it works. So much nicer. Yeah.
00:47:45
Speaker
One more thing on the whole, because we've talked a lot about UIs, and we've talked a bit about functional versus object orientation. And we've also talked about Android, which must have a lot of this. What's Kotlin's opinion on the right way to do user interfaces?
00:48:02
Speaker
Yeah, so Compose is the primary UI for building in UIs for Android with Kotlin. It's a Kotlin-only library, so it's taking advantage of a bunch of Kotlin features to be able to create a really nice program model. It feels declarative, but it's just using that DSL syntax in Kotlin to be able to give you something that looks declarative, but really is just Kotlin underneath the covers. And then Compose has a bunch of components, and you can
00:48:32
Speaker
use a bunch of those components together into what are called the composables and build a whole UI based on your composables. And so that is the modern way to build UIs in Android. And JetBrains took that Compose library and made it work on other platforms. And so it's a new programming model. Is there anything else on Compose that's interesting?
00:49:03
Speaker
I think that the programming model for me is nice. It's a whole lot better than writing callbacks and the older style of building a UI. But it's not actually very functional. I don't know if you've done Elm, but I love Elm's approach to UI programming because it is functional. For me, there's some
00:49:26
Speaker
things that when i'm in compose i'm like i wish this was just a pure function yeah but and it's not it's you know it's uh compose is managing the state underneath the covers and doing all sorts of clever things to make uh state state dealing with state efficient uh to be able to get high performance ui's and all that but um but it's it's a it's a different model of programming ui's than than you would do in the functional world with something like a home
00:49:52
Speaker
Is there, is there like a comparable architecture? If it's not like Elm, is it like React? Is it like using jQuery? Is it like Swig? What's the approach? I think that probably React would be the most similar that I've experienced, but I haven't done a whole lot of actual web programming with many of the modern web stuff like React or whatever.
Compose: Declarative UI with Kotlin
00:50:14
Speaker
I don't know how similar it is to React, but I think the main point is it feels declarative. You have nice language support for doing callbacks. Like when somebody clicks on a button, you need to do something to that. And then you can update state and compose.
00:50:30
Speaker
manages, oh, this state changed and this particular piece of UI is bound to that state, we need to obviously redraw that piece of the UI. So Compose does all that underneath the covers for you with that kind of connection between state, mutable state and the UI that is bound to that state. So yeah, that's part of the Compose runtime and Compose compiler kind of work together to make that all work.
00:50:57
Speaker
kind of transparently and efficiently is I think one of the important points is like you can do this, you can do this in a naive approach and I think have a lot of performance issues, but doing it in a way that works well for non-laggy UIs is a bit harder and that's what the compose folks have done. And I guess they're thinking about much lower power hardware because they're working on mobile phones all the time.
00:51:20
Speaker
Yeah, definitely. With Android, you've got to be thinking about the lower power devices that need to not use so many resources and all that. Let's talk a little bit about the future then, having got a survey of the language. You said you've been at Kotlin.com. If you've been at Google, the Google I.O. is happening as we're recording this, I think. You're making some announcements. What's on the future list?
00:51:47
Speaker
Yeah,
Future Enhancements and AI Integration
00:51:48
Speaker
so exciting stuff is the new compiler is a big, exciting piece because as Kotlin code bases have gotten larger, that has put more pressure on the compiler to be fast. And so the new compiler, the early benchmarks that we've seen on compiling Kotlin are that it can be around two times faster than the old compiler. And so
00:52:11
Speaker
That definitely has an impact on large code bases. And then things like when you're in the IDE editing code, you want to get code completion quickly. And as the code base grows, that code completion can get slower. And so just providing a better, more efficient way to be able to provide that code intelligence back to the IDE is important.
00:52:31
Speaker
And so this has been a big multi-year project of rewriting the compiler. And at Kotlin Conf, they announced that the new compiler will be the default in Kotlin 2.0, which I don't know the exact, I don't know if they said the exact timeframe for that yet, but hopefully sometime in the next year or so we'll be getting Kotlin 2.0 with a new compiler. So that's great. That's going to lead to kind of just a better foundation for moving forward and much better performance.
00:53:00
Speaker
So the code name for that compiler was K2. Solid name? The new compiler in Kotlin 2.0. So yeah, that's one of the big exciting things. Other exciting stuff was there was a bunch of announcements at Kotlin Conf around Kotlin multi-platforms with Kotlin Wasm piece.
00:53:18
Speaker
I think that's currently experimental, composed for iOS, also experimental, I think. So yeah, so there's a bunch of exciting things happening around Kotlin multi-platform announcements at Kotlin Conf.
00:53:33
Speaker
I was working on a project that we announced at Kotlin Conf, which is moving the default Gradle build configuration for the ecosystem around Gradle from Groovy to Kotlin. And so that was a good thing. Why not have Gradle supports Kotlin as the build DSL and so aligning around Kotlin?
00:53:56
Speaker
across JetBrains, Gradle, and Google to make Kotlin the default announcement we made at Kotlin Comp. So that was all good. I'd certainly like writing my builds in Kotlin. So that's been nice. So it sounds like the main thing that's happened is organizing for a larger future.
00:54:15
Speaker
Yeah, exactly. In many different directions, whether it's multi-platform or compilers or using Kotlin in more places like in the build.
00:54:28
Speaker
Just setting up things for a better future. But also, it's impacting developers already today. The developers that are using Kotlin, they're generally happy, which is kind of weird. Normally, in the language communities that I've been a part of, people are grumpy and complaining about all sorts of things in the language.
00:54:49
Speaker
And I think the developers that are using Kotlin are really happy with it. They always say that they're having fun, which is a good thing to hear for a language. Yeah, absolutely. It's funny how every language takes on a character, partly by the language and partly by the designers and partly by the community. Yeah, and I think with Kotlin developers, they seem happy. They seem like they're having fun. That's a good thing.
00:55:17
Speaker
Good, good. That's what we're here for. Getting stuff done and enjoying it along the way. I hope so. Yeah. I mean, I've definitely been part of language communities that just feels like a lot of thrashing and a lot of pounding my head against the wall in various ways. And yeah, I don't feel that much in the Kotlin community. So that's been good. That's really good. That actually leads me to one last question I have to ask you.
00:55:46
Speaker
One last challenge in question, I think. Bashing your head against the wall, the hot topic right now is getting artificial intelligence to support us as programmers.
00:55:57
Speaker
Will we be getting AI to help us write Kotlin? You're at Google, so you should have great answers to that. This is well-timed because just yesterday in the Google I.O. developer keynote, there was a lot of AI stuff. One of the pieces of that was they have something called Android Studio Bot, which is now integrated into the preview releases of Android Studio.
00:56:24
Speaker
and it allows you to have a chat-like experience to help you write your code or explain your code. So you can highlight a piece of Kotlin code and say, Studio Bot, explain this to me, and it will explain it. You can go into Studio Bot and say, Studio Bot, write something that will render an image for me with compose, and boom, there's your code snippet, and you can pull it right into your code base. So yeah, that was actually the first time that I'd seen Studio Bot,
00:56:52
Speaker
was yesterday watching the developer keynote. I was like, this is really cool, integrated right into your developer tooling, having that AI experience helping you be a more efficient developer. Yeah, it's super exciting to see what's happened there. I need to go play with it because I just saw it yesterday and I'm like, okay, now I got to go actually try this stuff. That just happened to me in a similar role. The company announces something, you've got to play with this so I know what I'm talking about.
00:57:18
Speaker
Yeah. So at this point, all I've seen is the demo. It looked really amazing. Now I need to actually get my hands on it. You can test if it's actually as good as the demo were. Yeah, exactly. It was a live demo, which I was like, hey, I'm a huge fan of live demos. I'm like, if it works in a live demo, there's a better chance that it's going to work for me while I'm sitting in front of my computer, whereas I'm always a little leery of the pre-canned, pre-recorded demos.
00:57:48
Speaker
Okay, that to me is like a red flag that the path is not going to be as smooth for me as the user. Yeah, if you do a live demo, it proves you're prepared to put something on the line for reliability. So final question then, if someone wants to get started with Kotlin, are you recommending they start with Android Studio or what's my onboarding path?
00:58:13
Speaker
Yeah, so I think it depends on which platform you want to start building for. If you want to start building for Android, then Android Studio is going to be the right path there. If you want to start with other platforms, then you can just get IntelliJ, the community edition is free, and start writing Kotlin code. They've got some wizards to build out new projects and all that.
00:58:35
Speaker
And then for Kotlin multi-platform, you can also start IntelliJ and start creating multi-platform projects and targeting other operating systems. And then the Kotlin link website has all sorts of great getting started learning material and all that for people that want to dive in.
00:58:55
Speaker
But yeah, lots of resources out there depending on what people want to do. But maybe to your point, it depends on which platform you're interested in targeting for kind of what your entry point is into it and some different options there. Okay. That's a new one actually, where you're compiling to makes a difference to how you get started.
00:59:15
Speaker
That is, yeah, that is interesting. So if you're a server side developer and Spring is a great choice to start with, with Kotlin. And so go to start.spring.io. You can click Kotlin as the language and boom, you're like, get your starter project and can start writing Kotlin code for Spring. So yeah, kind of a few different entry points depending on what you want to build. But yeah, lots of, lots of great resources out there for developers to learn. Okay, cool. I'm going to append Kotlin to my list of things to learn.
00:59:44
Speaker
Yeah, let me know how it goes. Yeah, I will. To make sure that that getting started experience is great for you, Chris, because if it's great for you, then it's good for everyone. Work on EMAC support, dude.
00:59:56
Speaker
Yeah. I shouldn't have said that. I take that back. There are bigger issues than editor choice. I know. Yeah. It is wild in this space that we have a lot of different options for how we write our code. And I think it is important that we support everyone and their choices around that. So hopefully that space continues to evolve. One challenge at a time.
01:00:20
Speaker
Yeah, exactly. James, pleasure talking to you as always. I hope I see you again soon. Thanks for joining us. Thanks for having me. Thank you, James. As you just heard, James is the co-host of his own podcast called Happy Path Programming. So if you're interested in a bit of a role reversal, there's an episode on there where I go and tell him all about my love of Haskell. I'll link to it in the show notes. So if you really want, you can get two languages for the price of one this week.
01:00:50
Speaker
value. That's value. If you'd like to give a smidgen of that value back, please take a moment to like and subscribe. I know everyone asks, but I'm also asking because it genuinely does help. Or just drop me a comment. I'm doing this because I'm a developer who loves talking to developers. So come and say hi. There should be a comment box nearby. Or if not, my links are in the show notes, you can get in touch with me.
01:01:15
Speaker
And with that, I think we've written one and it's time for me to run elsewhere. I've been your host, Chris Jenkins. This has been Developer Voices with James Ward. Thanks for listening.