The Future of

Kotlin
How agile can language development be?

Andrey Breslav
Disclaimer: Talking About the Future
• We are planning things

• We are not promising anything

Outline: The Future of Kotlin
• Where we are today
• Our plans and vision
• How we work
• Our constraints
• Legacy
• Kotlin Loves You  community
• Q&A
Where we are
As of Kotlin 1.1, early 2017
Our creed
• Pragmatic Language for Industry
• Interop
• Tooling
• Safety

• For JVM, JS and Native platforms

Kotlin/JVM
• Age ≈ 1 year old

• Approx. 160’000 users

Kotlin/JVM: Some Users…

& the Big Banks

Server/Android = 50/50
Kotlin/JS
• Since Kotlin 1.1 (Feb 2017)

• JS Interop
• Dynamic types
• ts2kt + DefinitelyTyped
• React, webpack, npm, …

• Full-stack projects
• Common libraries
• Shared code
Kotlin/Native
• Technical Preview (Apr 2017)

• No VM
• Our own memory management
• Direct C interop

• Standalone executables
• Direct compilation to Linux/Mac/iOS/Raspberry Pi
• Uses LLVM
Plans & Vision
Strategic directions for Kotlin
The Two “Dimensions”
Paradigms

Metaprogramming

F
Coroutines
v 1.1

Scripting

Functional

OOP
Platforms

JVM/Android JavaScript Native Multiplatform

Platforms
JVM -> JS -> Native -> Multiplatform
Multiplatform Projects & Libraries
• Common module:
• header fun foo()

Common Module Common API & Impls

• Platform module: Headers without Impl
header
• impl fun foo() { ... }

impl impl impl

JVM Module JS Module iOS Module

Platform API & Impls

Vision: Full-Stack Applications

Web Client
Android Client
(JS/WASM)

Server
(JVM or Native)

Desktop Client
iOS Client
(JVM or Native)

Everything testable can be shared!

Possible Products
• Cross-platform mobile: iOS/Android
• All testable code can be shared (MVVM could help along)

• Cross-platform Game Development

• Embedded: from DIY (Arduino/Raspberry Pi) to Pro

• Data Analysis/Machine Learning

• Server-side/Microservices
Paradigms
OOP -> FP -> Scripting -> Coroutines -> Metaprogramming
Coroutines
• Almost-free threads

• Straightforward asynchrony

• On all platforms
• JVM & JS: already supported
• Native: WIP
Example: 100’000 Coroutines
val jobs = List(100_000) {
async(CommonPool) {
delay(1000L)
1 Can’t be done
} with threads:
}
OutOfMemoryError
println(
jobs.sumBy { it.await() }
)
Going Meta
Future metaprogramming features of Kotlin
Traditional Approaches to Metaprogramming
• Reflection

• Annotation processing (Java)

• Expression trees (C#)

• Bytecode processing/instrumentation
Jedi Metaprogramming
• Macros
• Compiler runs some of your code

• Multi-stage languages
How do I make
• You don’t want to
an know 
IDE now?
The Kotlin Way: No Macros
• Plugins for Compiler/IDE
• Uniform API, must support IDE features

• Supersedes Annotation Processing

• New declarations
• Transform existing declarations
• Generate bodies

• Built for Incrementality

• Enables analysis tools
• Custom caching & Invalidation events
The Kotlin Way: Other
• Common “bytecode” (for all platforms)

• Expression trees & compiler-as-a-service

• Source location parameters (call-site introspection)

• Reflection, of course
• May have limitations on some platforms
To Infinity and Beyond
Other Language Enhancements
Some more plans
• Value Types & Inline Classes
• Compact storage, newtype, return several things from a function…
• Type Classes / Concepts
• Structural types, Non-intrusive interfaces, Extension-friendly
• Immutable data
• For error-proof sharing, Optimizations, ...
• Scripting
• Performance, REPL, ...
Immediate Future: Kotlin 1.2
• Focus on maintenance
• Performance is a priority
• Bugfixes, infrastructure, some tooling improvements

• One major feature:

• Java 9 Support
Design and Development
On Managing Legacy, Love and Friendship
Pragmatic Language for Industry
• Kotlin is a Tool for Developers

• Elegance is great, but relevance is more important

• Not a research experiment

• More than a compiler: IDEs, Build tools, etc

Kotlin’s new today, but we look ahead

Legacy 
Can we just drop it?
Users won’t like it…
Compatibility Constraints
• Both ways: for 1.X.X updates
• Fixes
• Optimizations
• Tooling features

• Backward: for 1.X versions

• Adding language features
• Relaxing restrictions
• Adding library APIs
• Old code must work
Kinds of Compatibility
• Binary — Super-Critical
• New binaries must work where old ones did
• Run time — required
• Compile time — desirable
• Users may not have access to source code
• Source
• New compiler should understand old code
• Users are developers
• They can fix the code, but won’t be happy about it
• Java did this a few times (enum, assert)
Compatibility Modes
• $ kotlinc -language-version 1.0 -api-version 1.0

• Turn off new features

• Every feature has an internal on/off switch

• Restrict new APIs

• Libraries are annotated with API versions
So, can we drop legacy features?
Deprecation Cycle + Migration Tools
• Deprecate in 1.7
• Provide automated migration

• Elevate to error in 1.8

• Provide a flag to demote back to warning
• Keep automated migration

• Delete in 2.0

WARNING: Use with care! Dropping features is painful for the users.
How agile can
language
development
be?
Compatibility vs Innovation
Waterfall or Agile?
☹Waterfall
• Design -> Implement -> Test -> Release
• Ivory Tower

☺Agile
• Design -> Prototype -> Get Feedback -> Redesign
• What about compatibility?

community
How agile can we be?
• Open design process
• KEEP = Kotlin Enhancement & Evolution Process

• EAP builds – Early Access Preview

• No compatibility guarantees

• Experimental features
• Completely usable, but the design may change
• Requires an explicit opt-in
• We’ll try to minimize the migration pain
Summary
• Agility in design & development
• Open design process: KEEP
• Experimental features
• Deprecation cycles
• Migration tools

community
• Kotlin ♥ You 