Should Kotlin Be Your Go-To Language?

In the ever-changing landscape of programming, Eammon Boyle and Garth Gilmour have chosen Kotlin as their default language. Preben Thorø explores the reasons behind that choice and how this language could make your life easier.

Intro

Preben Thorø: I haven't prepared anything. Normally I would do so with these interviews. Back in the day, I was a Java developer and then I became an Objective-C developer. At some point, I went to the dark side and started doing IOS development, and I've been doing that recently most, but most recently Python actually, but what you're really working with is absolutely new to me, so I decided instead of preparing anything, why not just go along.

Garth Gilmour: Excellent. We shall try not to give stupid answers.

Preben Thorø: And see where it ends. It might be that I leave the room...

Garth Gilmour: A convert. We will bring you into the light.

Preben Thorø: Oh, yes.

Eamonn Boyle: I mean, my laptop is over there. We can just start coding, you know. Maybe we should do that.

Garth Gilmour: All this talking. You know, talking is not for techies.

Preben Thorø: No talk, just code. We tried that as a theme at the conference a couple of years ago. We had a room which we called "No slides, just code."

Garth Gilmour: Yes. I have this rule. I call it "live coding summons the migraine fairy." Because everybody says, "When you teach, why don't you just go and live code everything?" And I said, "Because I've been traveling for 16 hours and I've eaten something that disagrees with me and I've got a migraine  and I've been doing this for 20 years, 4 days a week, so you can't always live code." You live code as much as you can, whenever you're teaching, but at the end of the day if you value your sanity there has to be some kind of a limit to it. So we like to say write copious, copious slides and then try never to use them but if you're having a really bad day, then the slides are there as the fallback.

Recommended talk: GOTO 2020 • A TypeScript Fan's KotlinJS Adventures • Eamonn Boyle & Garth Gilmour

Eamonn Boyle: I think it's like the third rule of Hollywood, you know. Don't work with kids, animals, and live code.

Preben Thorø: Exactly, yes, yes.

Eamonn Boyle: Yes, there are probably a few people on the planet who are smart enough to just walk into the room and make it up as they go but, sadly I'm not one of them. Are you?

Eamonn Boyle: Yes, I am.

How did you start coding?

Preben Thorø: So we have one of them here. I'm honored. What is your background? I'm just trying to find a clue where I can set in here.

Garth Gilmour: Oh, now you're asking. Eamonn, do you want to start?

Preben Thorø: The story of your life.

Eamonn Boyle: So I've been coding since I was very little. We had an Amstrad 464 with 64K. I think I went from an Amstrad 464 and then the next machine we owned was like a PC with 2 megabytes of RAM. So I never had any consoles or anything growing up. My friends had them, and I would make excuses to go to their houses and stuff, but I love all that retro stuff. 

But no, we had an Amstrad 464 with a tape deck. It was like what Woz was talking about waiting for your program to load and all this sort of stuff.

Preben Thorø: I know because back then Amstrad was kind of the other world. There was the Commodore world and the Amstrad.

Eamonn Boyle: Spectrum maybe is...

Preben Thorø: Maybe Sinclair too, but…

Recommended talk: GOTO 2020 • What We Left Behind - 10 Valuable Skills From The 1990s • Garth Gilmour & Eamonn Boyle

Eamonn Boyle: We have a Spectrum framed in the office. There's a lot of art, and our CEO loves art and there's some nice art scattered around the office, but my favorite is the Spectrum, even though it was the archnemesis of the Amstrad. 

So we had the tape deck, and you could load a program and it would run for 10 minutes making this high-pitched squealing noise, and then your program would run. You would see it and it was amazing, and it all started by just typing in from the manual. Like, blindly typing, and there were magazines and they had programs which would run games. You could write your own games, and at the start it was just, like, by rote, just coping, copying, copying.

Garth Gilmour: We both have the same experience because you're downstairs eating your tea and you're listening to the game loading upstairs then it's that sound- dammit, you know. "Back in a minute, mom." You're up the stairs.

Preben Thorø: I know that in the Commodore world it was not just a sound but a pattern on the screen too.

Garth Gilmour: Oh, yes.

Eamonn Boyle: Yes.

Preben Thorø: Some lines and you could just see if they got out of sync. That's a syntax error now.

Eamonn Boyle: Yes. But there were reams in these magazines. There were reams and reams of data sections that were just hexadecimal.

Preben Thorø: Sometimes, yes.

Eamonn Boyle: And just typing those in was horrendous and you make like one mistake and the program would crash. But I always just loved tech and from that to understand what the programs did and then through school competitions. Then my professional career has been started off mainly around, like, C++ and, like, Close to the Metal and telecoms and that sort of thing and then migrating more into desktop applications and moving into things like C#. Now we do everything: Angular apps and React apps and mobile apps and everything, all the platforms.

Garth Gilmour: I'm the complete opposite. I started out in the same space. When I was about 12 I got a Spectrum 48K and I plugged it in and it made multicolored blocks flash on the screen on Christmas day and wouldn't do anything else, and I always remembered my father saying, "Is that what it's supposed to do, son?" And me going, "I don't know." So it was broken, and we got a new one and then I started programming. The first program I typed in was for Space Invaders, from a book in the library, and I finished typing it in at 4:00 a.m. very, very quietly so my parents wouldn't know I was up.

Preben Thorø: Well, it was quiet on the Spectrum because of the…

Garth Gilmour: Oh yes, the rubber keys.

Preben Thorø: The rubber keys.

Garth Gilmour: Yes, real developers use rubber keys.

Eamonn Boyle: The Amstrad was solid. You knew you were pressing keys.

Garth Gilmour: But then I got Space Invaders typed in and I went to play Space Invaders. Then it said, "Syntax error at line 4." And I went, "What's a syntax error?" That's where it all started. So I taught myself to program games and so on, on the Spectrum 48K. Then I got obsessed with the social sciences and I wanted to be a criminal profiler, forensic psychology. So my first degree was in philosophy and psychology and I specialized in social psychology and how people make decisions in groups. At the time what was called human-computer interaction and computer-mediated communication which was all new at the time which was how when people went to online bulletin boards how that changed their patterns of discussion and how they became quicker to anger and it was easier to misunderstand things and so on. So I did that, did a master's degree in criminology, and then went out to become a forensic profiler. Only to discover that there were only three open jobs in the UK and all of them were taken.

Preben Thorø: Well, you only needed one.

Garth Gilmour: Yes. So I starved, and then I came back. I was studying in England at the time. So I came back to Ireland and I looked around for jobs and I said, "People are getting paid to program? People are getting paid to program?" Then I did a master's in IT mainly to give myself a year to teach myself things and then I got a job as a junior developer and everything just went on from there. So I worked as a developer for four, five, or six years and I enjoyed it, but I was kind of casting around and trying to find some way to use my background in psychology, a little bit more, play to your strengths. So the opportunity came up to become a professional trainer, working for an IT training company. So I thought, "What the hell? I'll give it a go. I'll probably only last three weeks." That was about 15 years ago. So I started out teaching C++ to C people, then Java to C++ people, then C# to Java people, and then everything to everybody, because as you know, our industry can't make up its mind. For the last three or four years, we've been specializing in Kotlin.

What moment in time would you like to freeze?

Preben Thorø: So if you had the chance to go back in time and freeze time at any point what would you do? Where would you stop?

Garth Gilmour: What about my life would I change?

Preben Thorø: No, not really. What I was doing around that time back in the Amstrad days or would I just freeze around the C++ days or...?

Eamonn Boyle: No, I mean, I had a lot of nostalgia for my C++ days when I started moving into the higher-level languages and all the managed languages like C#. I was like, "Oh, I remember the C++ days when you had to know all the bits and the bytes, and you had to know where the addresses were." Then I was teaching a clean code course. It was using C++ 99 with like TR1 and I was converting some examples and saying, "Ok. This is how you would write clean code." I was just finding it so difficult. C++ 17 and 19 have improved things, but I had this nostalgia that then when I went back I was like, "Oh no, that's horrible. I understand why I moved away from it."

Garth Gilmour: I think you always remember the good parts more than the bad parts, and for C++ I always remember the intellectual struggle and I enjoyed the way it took real effort to understand the language. Reading Scott Meyer's book about a dozen times and then finally understanding something and really enjoying that, but at the end of the day, I wasn't writing a lot of production code. So there are certain things about every period that you enjoy but I don't think there was ever like a golden age of coding that we really want to go back to I think. You know, development has never been as good as it is right now.

Eamonn Boyle: So I wouldn't wanna freeze time. I'd wanna keep going because new things are coming out all the time, and when I look back at that older code I can be more expressive now. I can describe the problems more effectively with modern languages. Things like Kotlin allow me to express myself in code in a much more elegant way, in a much simpler way so then I can concentrate more on the customer's issues rather than, "Okay. I understand what I need to do. How do I do the translation?" The translation is simpler. So I'm just waiting for, "Ok. What else is coming tomorrow?" I wanna see tomorrow. I don't wanna freeze any earlier time.

Garth Gilmour: I think one of the best things that have happened in terms of agile is the fact that we now let junior developers talk to customers., I remember back in the day when there were, three layers between you and the customer, and all you had was a use case report which might've been very good. It might've been very bad, but that was your only source of truth, so you were like a medieval monk just looking at these two sentences trying to work out the different permutations of what they might mean and so on. So I don't wanna go back to that.

Why is Kotlin your favorite language now?

Preben Thorø: So Kotlin, is this your favorite programming language right now?

Eamonn Boyle: I would say so. 

Garth Gilmour: It's that favorite language… if somebody gave me a team of developers tomorrow and said you have to write an enterprise app, it would instantly be Kotlin. I mean, my favorite programming language is XSLT, you know what I mean. So I love just hacking around in XSLT…

Preben Thorø: Oh, you're a rare species.

Garth Gilmour: Yes, yes, yes. You know, so in fact, my friends will tell you any programming language I say I like. It's kind of like the death touch. They immediately say that language is dead, you know, but Kotlin is absolutely the best language if you have a team of developers of varying skill sets and you want to get something quality out the door as soon as possible.. So it's in that sweet spot for modern development, and that shouldn't be surprising because that's what it was designed for.

Preben Thorø: But why? So other languages develop too?

Eamonn Boyle: We see a lot of similarities between modern languages. If you look at snippets of something, like  Swift or snippets of Kotlin or even C#, there's a lot of similarities in the features. Jon Skeet is doing a talk at the moment about nullable types in C#. So C# eight is getting this ability to define types as nullable and non-nullable, and this is something that Kotlin has already. So we do see the languages leapfrogging each other and they have their place.

Recommended talk: GOTO 2019 • Nullable Reference Types in C# 8 • Jon Skeet

Garth Gilmour: That's the thing. A lot of people who are new to the industry kind of freak out a little bit and they say, "Look, I'm scared by the polyglot programming, by the number of languages. I just barely feel that I've learned Java or C# but should I be learning Swift? Should I be learning Kotlin or Scala or Erlang or whatever it happens to be?" The thing that we teach is that all of these languages are kind of converging in the same space. So if you were to draw a graph of all the different language features and so on, there's kind of a hotspot that everybody's converging in.

And Kotlin, because it's a more modern, more recently designed language, it pretty much started off in that sweet spot that other languages are moving into. So C# is adding features. Scala is taking off features and so on. Everybody is heading towards the same area. So you could have the same experience that you have in Kotlin by saying, do Scala but don't use all of that stuff, ok? Or do C# but use this newer stuff and so on but Kotlin is just there already.

Eamonn Boyle: So I always look for the features that allow me to be expressive. So there's like a series of things that I'm now spoiled with, I've used in other languages, and then when I go to a language that doesn't have them I get frustrated."Okay. .I can't express myself as clearly." So things like extension methods and null safety, smart casting by the compiler. I obviously want a statically typed system. I prefer that because it gives me autocomplete and refactoring and I'm now in a world where I need good tooling so I can keep my code clean continuously instead of going, "Okay. It could be better, but I don't have time." Now I do a shortcut and the code is cleaned up and I can say, "Yes, that expresses. That's gonna be more maintainable. That's a more expressive bit of code."

So for me, there's a certain set of features that I really like, and on the JVM, the most prevalent language is obviously Java, so Java Virtual Machine. I always find Java more frustrating, and, you know, there are historical reasons for this and some of this is designed by a committee and things move a little bit slower, and sometimes when you have someone who has a little bit more control and can just say, like a benevolent dictator, "This is the way it's going to be," things can move a little bit quicker. I love C# and I like developing in .NET and if there are certain organizations that are Microsoft houses, that's the stack they will use.

But in the JVM there's more stuff written on it. The ecosystem is really good. The community is really good. The libraries and the solutions that are out there that you can leverage are really, really good. The big problem was Java. So for me, I don't like reinventing the wheel. I don't like the fact that there's a lot of churn in our industry, especially in front-end development, but for me there was a problem on the JVM and Kotlin is the solution. Kotlin allows me to be as expressive as I am in the .NET stack in the JVM. They've made really good engineering decisions like the interop is, like, a primary goal, so all of that legacy Java code that I have, all of that knowledge and the APIs that I know, I can just consume readily. 

We find that in the space of a week you are super productive in Kotlin. it's not, like, "Okay. I have to change my mental models and it's a real paradigm shift." It's seamless. But now I say, "Okay. Well, that's neater."

Betting on Kotlin

Garth Gilmour: That's why as a company we made a bet on Kotlin about four years ago. We don't get royalties or anything out of it. We were just doing a lot of work in the JVM. In particular, we just won tenders to do several major large Android applications, and the guys in the development team they'd been on Xamarin for a long time. They'd been doing Objective-C. They'd been doing Swift and so on, and they basically came to management and went, "We don't wanna go back to Java." So some of the guys in the training team had been playing around with Kotlin and we were saying, "Look. This seems really nice. We should give it a go." So they went off and wrote some prototype Android applications in Kotlin, and then they came back and said, "We want this, ok? We don't want Java. We want Kotlin for the next project."

It worked out incredibly well on the development side of the business and that's why I then turned around to JetBrains and said, "Hey, would you like a classroom-based training course?" And they said, "Yes. If you're mad enough to write it, write it." So I went out and wrote it and they came over and accredited it and so on. 

The reason why we spend so much time doing Kotlin these days is simply that, as a company, we've placed a bet because we think it's the future, and we evaluated the others. I'm a huge Scala fan as he'll tell you, but the guys in the office just find Scala overkill. So they did the online training courses. They got a pile of the certifications and so on. They did a really deep dive into the language and said, "Look. There's a lot to like here but it's too complicated for what we're doing at the minute, you know. We can, you know, make more progress with something that's simpler."

Should all developers learn text-code?

Preben Thorø: One last thing. You've mentioned something about upcast and downcast, and null pointers as a reference, or whatever we call it. Well, I have an illusion that I understand this because I'm the same generation in this field as you are. So back in the day, we needed to know about memory registers and everything. I also have a feeling that we don't educate young people from that level and up…

Garth Gilmour: Well, it could use…

Preben Thorø: It's something we should.

Garth Gilmour: Yes and no. I mean, this is something that gets hotly debated, and as an educator this worries me, you know. So the standard question that people ask is, "Should all developers learn C?" 

Preben Thorø: Or at least text code.

Garth Gilmour: Oh yes, and for a while, I believed in this and I said, "Yes, all developers should learn C because this will give you a real understanding of memory management." But then I read a tweet that turned me around completely, and I forget the author of the tweet. I apologize, but they said, "Yes, C programming gives you an understanding of hardware as it was in the mid-1970s." 

Preben Thorø: But it still gives me a feeling about why I should avoid doing this or that rather than just that I should, but why?

Eamonn Boyle: I think there's an awareness that you have to have, but there's so much abstraction between what you're writing and your source code and what actually runs in the metal now. You have the optimization of the initial compilation step. You have the just-in-time compilation step. You have the operating system. You have all of the different layers within the hardware, within the processor, in the floating-point units, in the different levels of cache. We find now that if you look at the complexity of algorithms, we find that some algorithms which are less efficient on paper are more efficient when we do simple linear searches and things like this because of the hardware. The hardware sympathies there with cache lines and things like that.

So  I'm like you. I think that we should teach some of the fundamentals. We should understand about the architecture, about operating systems, about some of these things, but whenever I'm writing code, my first thought is always towards the readability of the code and how easy is this gonna be maintained and does this express my ideas. Performance is always the second thought. Now, if I have two solutions and they're equally readable and I have a hunch that this one is going to be more performant, ok. I'll go this way, but normally what I'm focused on is readability. If performance is a concern then what I will do is I will write some performance tests and I will measure it because that's the only way to do it. So the knowledge from understanding architecture doesn't have as big an impact as you might think.

Garth Gilmour: Yes, I think you're completely right that we need to give developers a kind of underlying understanding of what's really there, but as Eamonn says, there's just so much. You could talk for an entire week and we know performance consultants who could just talk to you for an entire week about nothing, but the dynamic optimizations done within the JVM as it's looking at your code and profiling it on the fly and so on, and then as you say, with the cache lines and all the stuff that's in modern hardware and then what the compiler is doing and so on. We know performance experts who teach courses where they show you two versions of the same code, you know.

With my 1980s understanding of hardware, I would be willing to bet all the money in my wallet that the one on the right would run faster but it's actually the one on the left. So a little bit of knowledge is a dangerous thing. 

At the moment if you're a developer writing code you're sitting atop a huge tower of optimizations, and the question is what understanding do we need to give junior developers or all developers without overloading them? And that's a very open question at the minute. So we can't write code completely ignoring performance. On the other hand, we can't all write code like, we're writing a Stock Exchange or for NASA or something like this. We have to find a kind of sweet spot between the two for most people most of the time.

Preben Thorø: Brilliant. Let's keep it here.

Garth Gilmour: Yes.

Preben Thorø: We could go on forever I think.

Garth Gilmour: Yes, talking is what we do.

Preben Thorø: And well done. Thanks a lot.

About the interviewers

Garth Gilmour gave up full-time development back in 1999 to teach and mentor full-time. Since then he's delivered well over a thousand courses and workshops to all kinds of programmers from all kinds of backgrounds. He started teaching C++ to C coders, then Java to C++ coders, then C# to Java coders and now teaches everything to everybody, but specializes in Kotlin.

Although self-employed for most of this career, he came to roost six years ago as head of learning at Instil. As part of that role he speaks frequently at meetups, presents at conferences and co-organizes the Belfast BASH series of developer events.

When not at the whiteboard he coaches Krav Maga, lifts heavy weights and fights nerf wars with his kids.

Eamonn Boyle has over 15 years working as a developer, architect and team lead. For the last 2.5 years he’s been working as a full-time trainer and coach, authoring and delivering courses on a range of topics to a broad range of delegates. These include paradigms and technologies from core language skills, frameworks to tools and processes. Experienced developer, architect and team lead.

He has also spoken at a number of events and meetups including .NET Developer Guild, BASH and GDG Dublin and aided in the delivery of workshops at KotlinConf, GOTO Amsterdam and RebelCon.

Eamonn enjoys a good film, loves a good debate on current affairs and practicing his photography skills.