Kotlin Lead Language Designer Andrey Breslav on Android Support, Language Features and Future Plans

Show Notes

What does becoming a first class language for Android support mean for Kotlin?

• 2:00 Android developers have an official guarantee that the language will be supported, which will lead to further adoption of Kotlin.

How easy is it to use Kotlin for Android applications?

• 2:50 From Android Studio 3.0, Kotlin will be available by default, so no additional plug-ins are required.
• 3:00 It’s now possible to create a new Kotlin project from scratch, instead of having to migrate an existing (or empty) Java project first.
• 3:05 We’re working to ensure Kotlin and Java reach feature parity.

What does Kotlin and how does it fit into the Java ecosystem?

• 3:25 Both Java and Kotlin compile down to [JVM] bytecode.
• 3:40 This means it’s possible to use familiar code patterns and existing libraries, including using existing Java code.

What does feature parity mean?

• 4:00 Specifically, the IDE feature parity - the inspections, refactoring, linters and so on.

What about the language?

• 4:30 Anything you can write in Java today, you can write in Kotlin. 
• 4:40 In the same project, you can call Java from Kotlin and vice versa without any performance penalty.

What does the experience look like?

• 5:00 It looks like a normal function call - the same packages and libraries can be used from Kotlin as from Java.

What about types?

• 5:15 Kotlin is smart enough to convert Java types to Kotlin types automatically at compile-time - so there is no run-time performance penalty.
• 5:30 We recognise all Java classes, including Strings, Collections etc.
• 5:45 The Kotlin compiler automatically annotates certain types based on the API regarding which can return null and which can’t.
• 5:55 The existing Java types are enhanced and are more safe as a result.

Kotlin and Swift are very similar - how did that happen?

• 6:30 I don’t have first-hand information about why - both projects were started at about the same time, but JetBrains published the description fairly early on.
• 6:55 I’m happy when I see similarities in different languages, because designers of languages can learn and be inspired from each other.

Where did Kotlin come from?

• 7:40 We started talking about ideas in 2010, and I came in about the right time.
• 8:20 We announced sometime in 2011, and a preview released in 2012.
• 8:40 February 2016 was Kotlin’s 1.0 release.

Why create a new language instead of using an existing one?

• 9:10 Any tool has many requirements. We had a large codebase and knew what patterns made good Java code.
• 9:35 There were options with Groovy and Scala, obviously.
• 9:40 It had to be fast, that is toolable, and with Groovy and Scala saw problems with the tooling.
• 10:00 With dynamic languages the tooling can’t be as good as with static languages, because the dynamism means the compiler doesn’t know about the program, so can’t help you.
• 10:30 Dynamic languages also tend to perform faster since dynamic method dispatch is slower than compiled method dispatch.
• 10:40 With Scala, it has a strong statically compiled type-system, but Scala isn’t easily toolable either because the type system is so rich.
• 10:55 It isn’t easy for the tooling to be fast because of the complexity of the type system - at JetBrains we have an IDE for Scala and so know the issues there.
• 11:05 Not only is Scala challenging for machines to understand, it’s also challenging for people as well.
• 11:10 We believe that everyone in the team should be able to understand everything, which we felt we couldn’t do with Scala.
• 11:20 There are also some decisions about the heavy use of implicits, that are inherently difficult to understand for maintenance of the codebase.
• 11:30 We did try both Groovy and Scala in production, but there are use cases that they didn’t cover so well, and we felt that was space for something else.
• 11:50 We thought we (as a company) were the right people to fill this space, since we have the experience of multiple languages and the tools that are used to write programs in them.
• 12:00 We worked towards making the the user experience great.

What safety features do you get when you use Kotlin?

• 12:40 Nullable types - the Kotlin compiler knows which references can hold null and which can’t, using a question mark at the end to indicate nullability.
• 13:10 It’s also possible to explicitly unwrap places where the developer knows it cannot be null (using the !! operator).
• 13:30 The collections are also type safe: in Java, the collections are mutable by default. 
• 14:00 Kotlin provides a different view in a type system; we have read-only interfaces and mutable interfaces.
• 14:40 We also have smart casting; with an if block that tests something is an instanceof a type, you don’t need to explicitly cast that within the block.

Can the language be memory safe as well?

• 15:30 Under the hood it’s using the JVM, and the JVM has a memory model.
• 15:40 Kotlin native will likely have a different memory model, probably more relaxed than the JMM.

Kotlin feels like it can be used as a DSL. Is that the case?

• 16:20 We were looking at other languages like Scala, C#, Ruby and so on.
• 16:35 We looked at how we could add features to Kotlin to do the same kind of thing.
• 16:40 We can use a typesafe builder, which looks like declarative code, but is a collection of function calls.
• 17:00 You can do the same thing in Groovy, but there isn’t the typesafe guarantee. We found a way to do that in a typesafe way for Kotlin.
• 17:15 That’s been used heavily in applications, build scripts, user interfaces, so it’s been a good idea.

What are extension methods and trailing lambdas?

• 17:55 If you have a function whose last argument is a lambda, you can write this after the parenthesis instead. This is similar to Groovy (and Swift).
• 18:15 Extension methods are more interesting - unlike adding methods by subclassing an existing class, which requires additional types to be created and can’t be used with existing instances, or with final classes.
• 19:00 Extension methods look like they are functions on a class, but in fact they are a static method elsewhere that takes as its first parameter the target type.
• 19:30 These work in the same way as existing StringUtil type classes, but allow those methods to be used directly on String instances.

Go is an opinionated language. How opinionated is Kotlin?

• 20:30 We are trying to find a balance - in some opinionated languages like Go and Python have One Way To Do It.
• 20:45 Opinionated languages tend to be small, and so you can’t add features to the language.
• 21:05 More widely adopted languages tend to be a bit bigger than the opinionated ones.
• 21:10 We are trying to achieve a balance - we aren’t adding everything, but we aren’t being strict in only having one way to do everything.
• 21:35 We are trying to be pragmatic - if it’s inconvenient but we have to move away from our opinionated position to make it convenient, and it’s important, then we’ll do it.

What are coroutines?

• 22:15 We want to make writing asynchronous code easy.
• 22:25 The goal was to take away the pain of writing asynchronous code explicitly.
• 22:30 When an asynchronous program works, you have a call that has some dependent logic that requires the call to succeed.
• 22:45 When the call completes, you then may want to kick off another asynchronous computation.
• 22:50 You end up with callback hell, where you have many nested callbacks.
• 23:05 The idea with coroutines is to make writing asynchronous code as simple as writing synchronous code, by getting the compiler to generate the callback code.
• 23:30 So you end up with code that is easy to read and understand, and is maintainable, but is asynchronous.
• 23:40 You can think of coroutines as being similar to very cheap threads.
• 23:50 When a coroutine is stopped, it doesn’t need to pause the underlying thread.
• 24:00 You can also have tens of thousands of coroutines, where you couldn’t get tens of thousands of threads on a system.
• 24:10 It’s a way of doing asynchronous scalable programming.

What’s the relationship between threads and coroutines?

• 24:20 Go has goroutines, which is similar to Kotlin’s coroutines.
• 24:40 C# introduced async and await, and in Kotlin we made it flexible for library writers - we don’t have keywords async and await, but a library can expose coroutine support.
• 25:00 On the semantic side, it’s mainly the same as in C#.
• 25:10 It was a challenge to introduce them into the language without syntactic overhead.
• 25:20 Adding coroutines only required one minor keyword.

You also target things other than the JVM though - what’s the plan?

• 26:00 We have started Kotlin for JavaScript, and Kotlin Native, based on LLVM to compile down to native code as a standalone executable.
• 26:20 We want Kotlin to run on any platform - where the JVM is available, you can use that, but if not you can compile down to native.
• 26:40 We can target small devices like the Raspberry Pi, or iOS, or Unix command line standalone executable, and coming soon to Windows.
• 27:10 The goal is to have a full stack code reuse between platforms, so you can have the same code on the client and the server.
• 27:20 You can also share code between clients - so the same code can be used for Android, iOS and in the browser.

What else is on the roadmap?

• 27:55 Further afield there is a question of how we do metaprogramming in Kotlin; we have attributes and can do introspection - at least on the JVM.
• 28:10 Others are interested in macros - we are reluctant to do this because it causes challenges for the tooling.
• 28:20 These could include compiler plugins in the future, but it’s not on the roadmap for now.

Comapnies and Langauges Mentioned

Google
JetBrains
Kotlin
Swift

Interested in modern languages?  Check out this panel discussion hosted by Martin Thompson on 'What's Next for Our Programming Languages".