172 iPS Kotlin vs Swift with Andrew Rahn

00:00 2799
Download MP3

1:10: Introduction: Andy Rahn

  • Works for Iconfactory

  • Swift

  • Lua

  • Kotlin 6:20: Kotlin: What it is, who is responsible

  • New language by JetBrains

  • Similar to Swift but for Android 10:50: Future of Kotlin

  • Google looking at Kotlin?

  • Running on the JVM 15:45: Benefits of Kotlin: Familiarity

  • Feels familiar; same syntax as Swift

  • Shares similar disadvantages 19:20: Interacting with Java API

  • Nullability

  • Bridging 23:20: Kotlin vs. Xcode

  • Kotlin has many more features

  • Debugger in Android Studio difficult to use 25:20: Unit testing in Kotlin26:10: Kotlin is stable

  • Swift is moving more quickly 29:40: Swift vs Kotlin: Advanced features

  • Generics

  • Compile time analysis

  • Reactive extensions 37:25: How many are using Kotlin?


Skillshop.me (Andrew)Dylan and Dustin Bruzenak episode (Andrew)Freelance Remote Conference (Charles)Webinars(Charles)The Sword of Shannara (Charles)Reactive extensions (Andy)Cocoaheads(Andy)Smile Train Charity (Daniel)iOS 10 Messages apps and stickers (Andy)


Hire.comAndy on Twitter


Charles: Hey everybody welcome to episode 172 of the iPhreaks Show. This week on our panel we have Andrew Madsen.Andrew: Hello from Salt Lake City.Charles: I'm Charles Max Wood from Devchat.tv. We have a special guest this week, and that's Andy Rahn.Andy: Hello.Charles: Did I say your name right?Andy: Yeah, you did great. Thanks.Charles: Alright. Do you want to give us a brief introduction?Andy: Sure, about myself?Charles: Yeah.Andy: I actually work for Icon Factory. It's a company that does icon design, app design, and also app development. Most of the designers are in North Carolina but I work with our development team here in Minneapolis, Minnesota. We work out of a co-working space called Cocoa. We do a variety of mobile app development for a bunch of different clients. Prior to coming here last fall, I actually was at Adobe for about 15 years and there I worked on a variety of apps. Most of my time I spent working on Lightroom and a couple other photography apps.Charles: Very cool. Yeah, we had Dylan and Dustin Bruzenak on the show a while back.Andy: Yep, I work for them.Andrew: That was a memorable show. Those two can talk. Andy: Yeah you have to be careful not to sit between the two of them because it's from both sides.Andrew: Yeah, I liked that episode. What kind of development do you do?Andy: Pretty much what anyone will hire us to do. Lately, I've been working on an iOS app in Swift. It's actually a dating app our client’s having us build. Earlier this year, I was working on a transit app for Android and that's where I discovered Kotlin. Just learning those two languages, this is the first time I've written an app for either of those languages. It was really interesting seeing the parallels.Earlier this year at--there's a developer conference in the twin cities called Minnebar. I just threw together a talk that kind of compared the two languages to present there and that's where Jaim, who has been on your podcast, found out about my interest in that topic. Charles: Yeah, Jaim lined us up and then he bailed on us.Andrew: Yeah, he's at 360iDev I guess.Charles: He's at the conference, I didn't check which ones were running.Andrew: I bet it’s 360iDev that's going on right now. You mentioned you were at Adobe before, what language and frameworks and such were you using before you started doing Swift and Kotlin?Andy: Well, Lightroom is actually a little bit unique in Adobe's app portfolio because it's written largely in a language called Lua which you may or may not have heard of. It's similar to JavaScript, it actually has been used in a lot of video games. World of Warcraft for example uses Lua. It's a scripting language but it does compile them to a byte code, that was kind of special feature of how Lightroom moves together. Andrew: I think I actually remember hearing early on when Lightroom was newer than it is now that they were using Lua. That was interesting at that time because I don't think I've heard of Lua before that. Andy: Yeah, Lua. We started about 10 years ago, actually more that now. At that time, Lua was really far ahead I think in terms of some of the language features. It had closures which was really a neat feature of a language but it is also a very simple language in terms of having a very small set of fine data structures. That made it, at least we thought, easy to learn and yet very powerful. Obviously as we started developing that app, we built our own complexity, so you always have to be on the guard for that. Other than Lua obviously, Adobe’s most of the apps are either built on C++ or in the kind of default language of the platform. Java for Android, or Objective C for iOS and Mac. Charles: How did you discover Kotlin? Andy: Actually, it was a friend of mine who suggested when I was kind of doing some research on Android. Actually, a guy from Lightroom dev team, Matthew Johnson, he used to say, "All the cool kids are using Kotlin, you should give it a try." At the time, I started our Android project, Android did not support the latest language features from Java. Specifically, it didn't have any closures or blocks. I just know from experience that writing everything as an anonymous inner class is a really verbose way to go so that right away was a very appealing feature of the language that you could be a little more concise on how you write your code. Actually it's interesting. When I learned about Kotlin, their whole philosophy is one of, "Can we make it more easier to be more concise with expressing what you want to accomplish?" Even though today, they do have support Android for Java 17 and some features of Java 18 including closures now. I still think Kotlin's an interesting language because of the other things that they've done to make it more concise and easy to use.Charles: You gave us a whole bunch of information comparing Kotlin to Swift. I think that's part of what would be interesting at least to our audience is what do I already know that's going to make development on Android easier without having to go to one of these cross-platform systems like React Native or something like that.Andy: Exactly. That actually is one of the appealing things as well for me because in switching between these two projects, I end up finding thing. It was really funny like sometimes the differences are so small it's literally like a Kotlin or the little hyphen greater than arrow symbol. Other times, syntax is exactly the same. I think for someone who knows Swift already and has been called upon to develop something in Android, then this should be a good language for them to look at. Andrew: I'd like to back up just a little bit and give maybe more of a beginner overview. Our audience is a bunch of iOS developers. A lot of them probably have not done Android development, have never heard of Kotlin in the first place so can we talk a little bit about what Kotlin is and who's responsible for it, and how it's getting used and whatever?Andy:       Sure. For a Swift developer who's maybe considering building an Android application, the first thing you do is you look at Java. That's how Google put together the API for Android. Kotlin is actually a new language that was put together by JetBrains, that's actually the company that produces the IDE that you build Android apps in, Android Studio's is built on top of JetBrains' IDE. That company produced this new language Kotlin which is more simpler than Java, it's more efficient and it actually has uncanny similarity to Swift. There's actually a bunch of features in common that are most exactly the same or just slightly different than Swift and that's what makes Kotlin a really interesting language for an iOS developer who already knows Swift to get their feet wet on Android. The learning curve should be a little bit shallower.Andrew: You mentioned that’s something JetBrains came up with but then Android Studios is built on JetBrain so I sort of wonder what Google's relationship to your support of Kotlin is like?Andy: I don't actually know. That's one of the things in this topic is that I am also kind of an outsider. I'm not an expert on Kotlin or what its history is. I know it's been around for a number of years and I would assume that Google doesn't have any problem with it. Really, there's no reason they should because at the end of the day, Kotlin compiles to the exact same byte code that Java does. As far as an Android device or any Java virtual machine in fact would know, it is just regular Java code. There's really no problem with using it. It's not the first language that works that way. There's also JRuby and Groovy and a bunch of other languages that compile down to Java byte code like that.Charles: Yeah, in fact I think Ruby Motion takes advantage of the fact that you can essentially write Ruby code then use JRuby to run it on the JVM. There are other systems out there. I'm trying to remember the other one because there was another system that ran on Android that was specifically a flavor of JRuby. Any language that can run on the JVM runs fine on Android, you can write your apps in it. You have all the inoperability that you would expect, you can use all the Java libraries and everything else. Andy: Yeah, in fact there's even a version of Lua. I'd like to go full circle here. There's like JLu something, something I created which compiles down to Java byte code. I don't think that project was continued. I only did look at it once. Andrew: Well, I guess what I was getting at is that—I mean the situation is sort of the same on iOS. There are actually a lot of languages that you can use on iOS including Ruby through RubyMotion. Samron lets you use C Sharp, I don't know, I'm sure there are lots of others I'm not seeing here right now. But certainly know, there’s really Apple's official blessing except for C++ and Swift. I guess what I was getting at is is Google going to adopt Kotlin as sort of a real first class thing or is it always going to be sort of this third party thing that JetBrains is doing? It seems like it's maybe half and half right now because Android studio is sort of JetBrains thing but it's also the official way to write Google or to write Android apps now. Andy: That's a good point. I mean, obviously any time you deviate from the exact garden path that the primary developer has laid out for you, you're taking a small chance that you might not be in a happy place several years from now. But given that Android Studio is built on JetBrains' product, it seems as though that kind of relationship between Google and them is already really close. I didn't really have too much concern about using it.Andrew: I hope, I think there are a lot of us that hope that in the same way that Apple after really, I mean the history of Objective C goes back a really long time but after a long time with Objective C, Apple has come out with Swift and kind of moved to replace it with a modern language. I think that there are some people that hope Google would do the same thing and maybe caught on a zit. That's sort of what I'm hoping. Andy: It could be. Or it could be something Kotlin-like, that's even better.Andrew: There were some rumor of Google looking at Swift actually which is interesting and sort of skeptical of but it would be cool. Charles: The thing is though that there's certain advantages that you have to adopting something like the JVM where there's now a standard way to allow people to write whatever language they want and then just have it run there. I don't know, I mean I could see them adopting Kotlin and then just leaving it running on the JVM and saying, "Look, the JVM is sort of the low level standard and you can use any JVM language to write it." Andrew: Yeah, there's a lot of argument there. I would argue that some of Android's real shortcomings are because they used JVM.Andy: That's fair.Andrew: Although you can write what do they call it, there's a word for their version of their framework so you can write it in C++Andy: It's essentially the JNI, it's not much of the Java's way of native. The one holdback I would say on the JVM is you can't really fundamentally change how classes work and that's one of the places where Swift and Kotlin deviate. Swift actually introduces enums and structs that have value semantics. I don't think that's something that you could add to the JVM, not that I'm an expert on how JVM works but from what I've seen, everything there is an object and everything there garbage-like, it was as an object. Adding in a complex value of semantics is maybe something you can't do on top of the JVM. Charles: One thing that I'm curious about is the JVM is garbage collected. In Swift, you basically have automatic reference counting. I'm wondering, is there really that much nuance. I know they work differently but do you find that one is more performant than the other or is a little easier to reason about the other or it is just mostly just the stuff goes away when it's not being used and you don't really have to think about it or what?Andy: Almost. It's almost that good. The one caveat would be if you write a lot of blocks or closures, you do have to be careful in Swift because a lot of times you're cutting closures and attaching those onto your controller or something either directly or indirectly. If you don't remember to mark yourself as weak, in those cases you can create reference cycle and that'll prevent those things from being released. You do have to be careful to annotate with weak ind Swift. The compiler helps you because in blocks you can't just reference a property on self without explicitly saying selfdot. As long as you get in the habit of realizing, "Oh, I had to say selfdot, I should become aware that I'm creating a reference to self here and perhaps add a weak to that. That's really the only place that I even see any difference. Obviously, a garbage collector don't have to worry about that so you can just have that in Kotlin.Charles: Right. Andy: With that said, I'll be honest, the more you have a deep understanding of how systems work, the more you're going to avoid those edge cases where things go bad. That's just a fact of life for any developer. If you're not really thinking about the fact that Kotlin's garbage collected, you might find yourself in a situation where things have disappeared because you didn't actually anchor them to anything and it got collected, and that could cause kind of weird unexpected behavior. That's just the cost of doing business. You got to have that kind of understanding. Charles: Yep. I'm also curious, let's say that I'm coming to this from Swift and I'm thinking Kotlin sounds good because I don't really want to go figure out the quirks of this particular version of Java that doesn't have all these nice features in it. What am I going to see in Kotlin that makes me go, "Oh, I like that?” Or, “Oh this is very familiar."Andy: I think first you'd notice all the things that are familiar. If you decide to add methods to a class, it's almost exactly the same syntax as Swift. The only difference is they use the keyword fun instead of funk. That's just one character different. You can add properties to classes in very much the same way. I think even the switching from using a colon to the arrow is just about exactly the same as Swift. Declaring blocks is almost the same except the argument prance outside the curly braces so it’s just a slightly different syntax. They behave almost exactly the same.One of the things about Kotlin is that they seem to have given you a lot of ways to do things with the idea being that in some cases it makes your code really sharp. If you have a function that calls another function, you can add that as a member to your class despite doing what looks like an assignment, you basically say say this function, you go to that function. What that means is you're just going to call that other function. In Swift, there's no such optimization, you actually have to put a curly brace and call it a function. It's three lines instead of one. The downside of that is, I suppose if you got into someone else's Kotlin code you might be like, "Whoa, what's going on?" Because there are multiple ways to get things done. Pros and cons there on that I guess. One of the other thing that's nice about Kotlin is they introduce their own sort of primitive types. Much like Swift has array and map and set instead of the NS variance of all those types, you just feel like you're dealing with a native, natural language container and Kotlin has that as well. The downside of that is you're still talking to an existing Java or Objective C in Swift’s case, API. That API probably wasn't written in Swift or Kotlin, it was written in the original language for the framework. You do have to bridge across from these nice friendly types that the new language gives you into the original type. Both languages do a pretty good job of that. It's actually really pretty seamless. The only sort of rough spot I ran into was in Kotlin. It's not really Kotlin's fault, it's just that Java actually has a lot of kind of linear sequence types, be it array or list and list an interface in Java and there's several actual implementations like array list and so forth. Unfortunately, a lot of APIs are sometimes written in terms of these different types. You have to take your Kotlin array or list and turn it into an array list or an actual Java array or something. There's ways to do all that, usually that's just a method you call at the end, turns one into the other but it does kind of get to be kind of hair raising. You think like, "How many different ways, I just had ten adds in a row. How many different ways am I going to represent that in this one program?" I feel like Swift actually has a little bit of the same problem in that there are lot of different sequence types. There's collection, sequence, array, and array slice. Some are protocols and some are struts. And then you throw and bridge them anyway. I don't know, that same sort of area has tripped me up in Swift. I was actually going to ask, my next question was going to be about bridging which you already started talking about but how is interacting with the Android APIs, which are of course Java APIs, from Kotlin and another thing going along with that? In Objective C, Apple has actually made some changes to Objective C specifically so it bridges more nicely into Swift. I take it that JetBrains can't do that. They can't induce Google to add new features to Java just so that Kotlin works better. I wonder if there are any rough edges along those lines because of lack of support in Java for Kotlin?Andy: Yeah. You actually nailed it on the head. Fortunately, the JVM is pretty explicit about how the APIs work so even though Kotlin is consuming, the API has a dock class file for all the things that say you're calling or subclassing. There are cases where the Kotlin language is trying to help you and it really can't make the right choice. For example, Kotlin just like Swift has explicit treatment of nullability. In Kotlin, things can't just be null willy nilly, you have to declare them using the question mark just like you do in Swift. However, if you're implementing a fragment and you are overwriting the methods, Kotlin can't tell in that context if any of the arguments coming in are nullable. It'll put question marks on all of them. That's not a problem except now when you go in to implement that method you have to deal with checking for null on all of those which makes you do explicitly as a compile area to access something that could be null. You can do that but then, what, do you just abort if--sometimes these parameters are guaranteed to be there, that's what the Android API says. Well you can actually go through and delete the question mark off the declaration of the over-written method and that will still compile. But if you made a mistake and it turns out that it could be null, it'll then crush at run time. That's like the one place where I really got bitten because I kind of just wouldn't question mark all these things because it's ridiculous. You just don't expect the system to call you with null arguments on some fundamental part of how your application works but you do have to be careful because in some cases sometimes, I'm forgetting exactly what method on a fragment I ran into but sometimes they can be null. That's one place.Andrew: That's really interesting. Swift goes the same way in 1.0, I don't remember exactly but Objective C didn't have nullability when Swift first came out. I think they imported Objective C methods with exclamation points, explicitly unwrapped. It sounds like the same thing as deleting all the question marks. Andy: Yeah, exactly. I would say the biggest improvement in Swift was not just the new features they put in 1112 but really the improvements to the SDK that made it work better.Andrew: Yeah and of course adding generics to Objective C which Java already has GenericsAndy: Yeah.Andrew: There's no direct analog there but I've actually spent the morning teaching a room full of Swift programmers who have never done Objective C. It’s been nice that Apple has evolved Objective C in concert with Swift so that they bridge really nicely together. Andy: I think the integration there is really well done. Andrew: I kind of think that language is only as good as tooling. I'm not really the type that thinks a language is great if I have to write the whole thing in them and run the compiler on the command line and get no code completion and no debugger and that kind of thing. I'm curious to know how the situation there is for Kotlin. It's JetBrains and they make IDEs so I have a feeling I know the answer but I want to hear from you.Andy: Yeah, it's really, really well done. In fact, in flipping back to Android from Xcode after being away for a while, I think it's better than Xcode in a lot of ways. The editor is really solid, it has a gazillion features. I mean, they still check your comments for god's sake. We even spellcheck the inter cap words and your variable names which you can turn off because maybe then. If you're one of these people who like to get to zero warnings, you have to spell everything. The other thing is their compiler is much faster than the Swift compiler. That's really one of the big pain points I have with writing a medium size iOS app entirely in Swift, it takes a while. When you switch into Objective C project you're like, "Oh my gosh, it's so fast to compile now."Andrew: It's getting better but still a long way to go. I definitely know what you mean.Andy: Yeah. Also, integration with the other parts of the IDE are pretty good. The debugger in Android Studio's, it’s kind of hard to use. It's got a lot of tabs, every edge of the window has tabs. There are like tabs on the left, on the top, on the bottom, and then even the bottom panel that you can tab between has its own internal tabs on the left of that panel. It's kind of a very confusing interface until you work your way through all that. That's not strictly limited to Kotlin though. That was just hard for me to learn how to use well. There's some other idiosyncrasies just in terms of the whole experience like the build messages go on one panel, the run time messages go into a different one, and then the Android log messages go onto the third window. It's not always clear like some things are going wrong where the clues are going to be. You end up kind of looking through all these places to find out what happened whereas it seems like Xcode has a more consolidated view of your one time messages at least.Charles: How is the testing story on Kotlin?Andy: Like unit testing?Charles: Yeah.Andy: Yeah, it's built right in. It works just fine. I haven't actually written any test in Java so I can't really say if the experience is unique to Kotlin. I think it's actually just Java or Kotlin both work pretty well. There's a little testing panel that kind of comes in the middle there and it looks at your tests if they pass or fail and you can re-run just one test. It's probably one of the testing support in Xcode. I think both of them are kind of fiddly at times but for the test that I did right, it was pretty straightforward. Andrew: If you've been writing Swift for any length of time at all, you know that Swift is changing and evolving really quickly and you are about to have the biggest change yet with Swift 3.0 coming out in probably a month or so here. What about Kotlin? Kotlin is older than Swift so I think maybe it's more mature but is it also changing quickly or is it fairly stable?Andy: I haven't really seen any breaking changes come along in the last nine months that I've been playing with it. On the one hand, it seems like it's pretty stable. On the other hand, when I think about kind of what is Kotlin's role in the Java ecosystem, particularly in light of Android adopting more of the modern features of Java 17 and 18, does it actually provide enough differentiation as it is today versus those to justify sticking around. If it doesn't, is it going to either kind of fade away or are they going to make some more leaps forward to say, "Look, we're once again way different than Java." I could see it kind of going both ways. It's kind of exciting to think that it could be more of the bleeding edge, maybe there will be some other new advancement in the language that you would get available first there because at least in my experience, it doesn't seem like Oracle’s like really pushing the Java language forward very quickly anymore. If there's going to be innovation, it may well have to come from an outside firm like that first. That'll be my best guess.Andrew: Okay, that's interesting. It's actually--I don't know if that was the answer I was expecting or not. It's funny because you've talked about how similar Swift and Kotlin are but Swift's moving fast and developing new features faster than Kotlin, that may not be as true forever. I mean some of the core syntax is not going to change.Andy: Yeah, a part of me would love it if they would actually align on some of the core syntax because some of the differences are so small. Part of me is like, "Come on, can't you just align on that?" You can almost make a preprocessor that would make kind of subset that you put into either, it's that close. One of the things I didn't mention about Kotlin, which this part of their project is a little further behind but they do actually have a transpiler that turns Kotlin into JavaScript. One of the other interesting opportunities in Kotlin is that you can potentially say you have no JS back-end to an app that has a service, you can potentially write some parts of your model and Kotlin can run the same code in both server and client. I feel like that's one of these kind of holy grail moments that a lot of different people are circling around. You mentioned Zamurd, you can do that with C Sharp but Zamurd isn't really how maybe a lot of people want to write their native apps and you got React Native with JavaScript so this is maybe another possible future for Kotlin there.Andrew: Yeah, that is interesting. There's some Swift transpiler that came out in the last week or so. Very, very, unfinished about--I think it's Shift.JS something like that.Charles: Oh, really that's cool.Andrew: Trying to find it and then pick it, anyway, somebody's doing the same kind of work on Swift. Is that a JetBrains project or is it a third party thing?Andy: No, JetBrains is doing that but they're a little bit behind. Probably they're figuring out and pioneering the features on the Java side first and then once the dust is settled I guess the Java team follows on behind, maybe that's how they do it. Andrew: I'm curious about some of the maybe more advanced features of Swift and by comparison Kotlin. Swift has some things like generics and really deep support for protocols and some stuff that's maybe advanced but not as often used. I think coming in the future to Swift would be—one thing I'm particularly curious about is the built-in primitives for doing asynchronous programming which is not nailed down at all but has been talked about for Swift. Andy: We can think about those. Generics we’ll start with. Obviously, Java has generics and Kotlin has them as well. I would say the generics work pretty well in both Swift and Kotlin in a similar way when you're talking about just having a generic type on a class or something. Swift takes it much further particularly, when you start mixing in extensions and protocols and how you can extend some generic types or implement additively kind of combine and extend things. Frankly, that area in Swift, I'm not very good at. It seems like everytime I try to go down the road like, "Oh, I'll take this generic type and this protocol and this extension." I end up with a different error message everytime I try it. Sometimes it's a linker error, sometimes it's a compiler error, a lot of times the compiler would just crash. It's been kind of a frustrating part of Swift for me and I see people using it and it obviously can be done but it seems kind of like black magic to me.Andrew: Well, you're not alone. I feel like an overall pretty competent programmer, I've been doing this for a while and I always try to get clever in Swift and then now, some this or that in protocol associated types and blah blah blah and then I go find some thread on the Swift mailing list where they're talking about, "Yeah, we're going to fix this in the future." I'm like, "Well, that doesn't really help me now." I'm more and more kind of avoiding some of that fancy stuff. Andy: I know. That's been my experience too. Kotlin can't provide a lot of that because pretty much all the stuff they're doing obviously has to just be compiled down to regular code. You can sort of extend in some small ways types but really all it is is kind of a compile time helper code. It requires on compile time analysis to be able to make these things available to you, essentially aesthetic analysis kind of thing. You can't feed a Java line object that happens to be an instance on whatever class and expect the extension on that to be picked up. It has to know a compile time that whatever type that is had this extended method on it or something. That's kind of the limit of what Kotlin is able to do in terms of extending things. I guess it protects you from just kind of these crazy weird problems that we're finding in Swift. I don't think that Kotlin would be able to do much more with that without some fundamental changes to JVM or something. They are obviously very clever people, maybe they'll a find a way but that seems to be the limit. Maybe a reflection though. There's always a way sometimes. Then you mentioned topple, that's kind of one of my favorite little fun feature of Swift, it's a great way for just kind of throwing values around if you have your return to things from this method, you don't have to create a specific structure to contain them and put them in there. Kotlin doesn't have true topple support but it does have this thing called pair which they have a language keyword called to, to construct a pair. Sometimes, you just want to return things, two things you can just say A to B and it'll return a pair of A and B. Obviously you could create a pair with a pair in it by saying A to B to C, you might have to use frames I guess to know what you meant there but that's probably not really the best pattern in the world. People will be looking at your code going, "What?" Andrew: Yeah, of course since Swift topples can have up to I don't know what is it, six elements or something like that?Andy: I've never run into the upper limit so I don't know.Andrew: I think there is an upper limit if I remember it right but no.Andy: The other thing you can do with Swift, I don't know if you knew this is you can actually name the arguments in your topple so rather than just having three things in order, you can actually say [00:42:27] whatever.Andrew: I've used that but that sort of like a strut that's just declared in line instead of declared anywhere else and I kind of, at some point--well for two, maybe that's okay, if I’ve got six named parameters, maybe I should make a strut.Andy: I definitely agree with you. One of the things that I've been using both Kotlin and Swift in combination with is this thing called reactive extensions. You’d asked about the async keyword and I guess one of the reasons that I haven’t been paying much attention to the async stuff that maybe coming in the future version of Swift is I've been spending a lot of time thinking about reactive extensions. The cool thing is Kotlin and Swift both have really good implementations of react extensions. It’s essentially a library that once you learn at one it translates over to the other just about like 85% maybe 90%. Some of the methods aren't named exactly the same thing which just drives me nuts. But by large, they're almost exactly the same. In reactive extensions, you do a whole lot of chaining of little piece stamp code and closure that returns some values and then another snippet of the code that takes these values as inputs and returns more values. In that context, these little ad hoc topples are really handy because sometimes you need to return two or three things but you’re literally only using it in the context of these two blocks that are recommended next to each other so having a strut declared way at the top of the filer or something just for that purpose would be really annoying. Andrew: I have kind of blanked out here now but there was something I was going to ask. Oh, I know what I was going to ask. One of the things about Swift that has made it a little difficult for me, somebody coming to the language that is learning it either for the first time or whatever, a lot of the resources that are out there are in Objective C, a lot of the iOS resources, sample code and stack overflow questions, that's changing pretty rapidly.Andy: Yeah, it's nice how fast it's changing.Andrew: What's the story on Kotlin? Does it have a good community around it?Andy: I have to admit, most of the sample code I find is still written in Java. One of the features of the IDE, believe it or not, is actually a really compelling Java to Kotlin converter. A lot of times you can just copy some sample code that was in Java and just paste in it and say convert syntax. You might have to create a new Java file or something but if it was a sizable chunk of code that you don't want to just re-type, it actually can convert it for you. It's a pretty straightforward conversion. Sometimes these converters do a horrible job. This is more or less pretty much straight up. That makes this problem of our example in Kotlin or Java a little less of a big deal. Andrew: Good. It's cool. What do you think, just adoption wise. Swift, I don't know, I don't have real numbers but certainly the focal people in the community have basically all switched to Swift and it's the thing people talk about, nobody really talks about Objective C anymore. I'm sure that's not true with Kotlin being a third party thing instead of the mainstream way to do Android development. Is there a good serious community and what percentage do you think of Android developers are using it?Andy: I don't have a really good estimate of that. I guess I'm still a newbie. Enough of a newbie, I’ve been doing Android for four or five months now, I can't say for sure. But on the other hand, it seems like there was almost never a time when I didn't have a question or something that I didn't find a stack overflow thread or a discussion on the mailing list that pretty much addressed it. I think there's a sizable body of people using it.Andrew: That's really what you care about, right? Is that there are enough people out there using it to solve problems so you don't have to solve them yourself.Andy: Yeah.Andrew: Eventually.Andy: Right and obviously, all of the libraries you might want to bring in, even if they're in Java or Kotlin, they are going to work just fine. That's all built into Android Studio basically built in—I forgot what their package manager is called I'm blanking on that right now but you can just declare an it brings in automaticallyCharles: Very cool. I hate to do it but we got to get into picks. Andrew, do you want to start us off with some picks?Andrew: Sure, I have three picks today. My first pick is going to be one of the same things as I picked last week. I'm going to keep talking about it until you're sick of hearing it or have all bought a ticket. I'm teaching a five-day immersive workshop to learn how to do Mac development. It's meant for people who are already iOS developers. Come to Salt Lake for a week, learn how to do Mac development. It's a lot of fun and you can actually make money doing it. We also have an online option so if you can't come to Salt Lake, there's a ticket that lets you watch the sessions online and still participate and ask questions or whatever. That is through a new thing that's starting up called Skill Shop. The website isskillshop.me. I'll put a link in the show notes and I'm sure I'll be continuing to talk about it. My second pick is going to be an episode of our podcast, episode 110. You already mentioned it earlier but this is an episode we did with Dylan and Dustin Bruzenak also of the Icon Factory's development arm. We talked about the business of building apps and they were a lot of fun. Hilarious, very talkative, they're brothers, twins maybe, I can't remember.Charles: Yeah, they are.Andy: Yeah, they're definitely twins.Andrew: We've recorded a lot of episodes of iPhreaks now and I can't honestly say that I remember every single episode that we recorded two years ago but I definitely remember that one so it's worth checking out. My last pick is one that has been on my mind a lot and is kind of something a lot of us in the community are thinking of. That is Daniel Steinberg also known as @dimsumthinking. He is a wonderful member of our community that has given a lot to us, is a really kind, caring, warm person that unfortunately has just experienced an incredible tragedy, the second one in his life which is way more than anyone deserves, certainly way more than anyone as good as he deserves. Please have Daniel in your thoughts and more concretely, his wife just passed away, he's asked that donations be made in her name to a charity that I will post details about, we'll post details about it in the show notes. Really, this pick is just about think about Daniel, check out his talks, he's a wonderful person. We're all sort of thinking about him and feeling terrible about what's happened to him. Those are my picks.Charles: Alright. I've got a couple of picks. The first pick that I have is something that I use on the website a lot. In fact, I'm going to pick a couple of things I have on Devchat.tv. I've made a couple of changes. The first one is that you can get the conference recordings now on Devchat.tv. If you want to get iOS Remote Conf or Freelance Remote Conf, both of which were excellent content. I think Freelance Remote Conf is probably one of the best conferences I've attended. I was very impressed with the content. If you're a freelancer or thinking about freelancing, then definitely check it out. I've set up after the fact or you missed the conference tickets for the recordings and you just go to the page. If you go to Devchat.tv/conferences, that will get you access or that'll show you where they are and then you can go from there you can buy tickets. It's $100 per conference. The regular price tickets were $200 per conference if that gives you an idea of what it cost other people. But anyway, terrific, terrific stuff. I'm also putting on a series of webinars so if you go to devchat.tv/webinars you'll be able to see that list as well and get tickets for those. Finally, one of the things that I do to relax is I listen to audiobooks. I also do that to help move ahead with my business so I listen to business books and self improvement books and things like that. But in this case, I've been listening to a fiction series that I read when I was in junior high. It's called The Sword of Shannara and anyway, it's just been nice to sit back and relax and listen to something that doesn't actually force me to engage my brain in the ways that I do when I'm working. I'm going to pick that as well. Andy, do you have some picks for us? Did we warn you about what picks are?Andy: Yeah. I was told. I have a couple. I guess I already alluded to some of them but I think one has to be reactive extensions which if you're dealing with asynchronous code and you are having trouble coordinating a whole lot of data coming into your system from different places, check out reactive extensions. It's available for Swift, Cocoa, Java, and JavaScript, there's probably 10 or more languages that have it. It’s some technology that came out of Microsoft. It's very powerful. It can be quite dangerous, I’ll admit, but I think given the right application it can really help increase reliability of code because it's much harder to make mistakes around these conditions when you deal with a code in the manner that they do. Another one that I would throw out there is if you live in the Twin Cities area anyway, we recently have started up our monthly iOS and Mac OS developer kind of get together once a month called CocoaHeads so I encourage people to look us up on the web and if you want to come here, just local person talking about various topics. We hope to keep that going into the future. Andrew: I was just going to say I second that and I'll expand to say that Cocoa Heads is a worldwide thing. Even if you're not in the Twin Cities, find out if there's a chapter near you and go. Cocoa Heads has been super important and valuable to me. Charles: It's actually how I met Andrew and Rod who used to be on the show, that's how I met him as well.Andrew: Oh, that's great. I guess you forgot that it's more than your local chapter because of those people you're interacting with obviously is. Another one, I'm super excited about iOS 10 messages app and stickers and obviously working for Icon Factory, we hope that we can have a hand in that exciting new thing coming to iOS. Check them out sometime in September when that release comes out to your iPhone. Look out for that.Charles: We talked about that a couple of weeks ago too so if you're looking for a discussion about it go check that out. We'll put a link to that in the show notes as well. Andy: Perfect. Those are my picks.Charles: Alright. Well, if people want to follow up with you, they want to see what you're working on or read blog posts or see what witty things you're putting up on Twitter, where do they go, Andy?Andy: You can find me on Twitter. I'm just @paddlefish. Obviously, you can reach us aticonfactory.com.Charles: One more question I have, I'm sure there's a story behind your Twitter handle.Andy: Yes, in fact, prior to me joining the world as a computer software developer, I was actually a biologist and I have a master's degree in fish physiology. My master's degree project was studying the North American Paddlefish. It's a very interesting fish species. It gets to be about six feet long and looks a little bit like a shark and it swims in the Missouri River in my home state of South Dakota. That's where I found it. That's my background and why I tend to pick paddlefish any time I can as a handle.Charles: Cool. Thank you for coming. We really appreciate this dive into Kotlin and hopefully there's some folks out there that were looking for an option for Android, go check it out.Andy: Well, thanks for having me.Charles: Alright, we'll wrap this one up and we'll catch you all next week.Andy: Thanks guys!

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.