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

About Me
•  Andrey Breslav
•  Lead Language Designer of Kotlin since 2010
•  Formerly a High School and College Teacher, and Researcher
•  Personal values: Freedom, Responsibility and Improvement
Outline: The Future of Kotlin
•  Where we are today
•  Our plans and vision
•  How we work
•  Our constraints
•  Kotlin Loves You J
•  Q&A community
Where we are
As of Kotlin 1.1, early 2017
Our creed
•  PragmaRc Language for Industry
•  Interop
•  Tooling
•  Safety

•  For JVM, JS and NaRve plaWorms

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/NaJve
•  Technical Preview (Apr 2017)

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

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

Metaprogramming

F
CorouRnes
v 1.1

ScripRng

FuncRonal

OOP
Pla$orms

JVM/Android JavaScript NaRve MulRplaWorm

PlaOorms
JVM -> JS -> NaRve -> MulRplaWorm
MulJplaOorm Projects & Libraries
•  Common module:
•  header fun foo()

Common Module Common API & Impls

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

impl impl impl

JVM Module JS Module iOS Module

PlaWorm API & Impls

Vision: Full-Stack ApplicaJons

Web Client
Android Client
(JS/WASM)

Server
(JVM or NaRve)

Desktop Client
iOS Client
(JVM or NaRve)

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

•  Cross-plaWorm Game Development

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

•  Data Analysis/Machine Learning

•  Server-side/Microservices
Paradigms
OOP -> FP -> ScripRng -> CorouRnes -> Metaprogramming
CorouJnes
•  Almost-free threads

•  StraighWorward asynchrony

•  On all plaWorms
•  JVM & JS: already supported
•  NaRve: WIP
Going Meta
Future metaprogramming features of Kotlin
TradiJonal Approaches to Metaprogramming
•  ReflecRon
•  AnnotaRon processing (Java)
•  Expression trees (C#)
•  Bytecode processing/instrumentaRon
Jedi Metaprogramming
•  Macros
•  Compiler runs some of your code

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

•  Supersedes AnnotaRon Processing

•  New declaraRons
•  Transform exisRng declaraRons
•  Generate bodies

•  Built for Incrementality

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

•  Expression trees & compiler-as-a-service

•  Source locaRon parameters (call-site introspecRon)

•  ReflecRon, of course
•  May have limitaRons on some plaWorms
To Infinity and Beyond
Other Language Enhancements
Some more plans
•  Value Types & Inline Classes
•  Compact storage, newtype, return several things from a funcRon…
•  Type Classes / Concepts
•  Structural types, Non-intrusive interfaces, Extension-friendly
•  Immutable data
•  For error-proof sharing, OpRmizaRons, ...
•  ScripRng
•  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
Value Types and Inline Classes
•  Newtype (vs typealiases)
•  Unsigned arithmeRc
•  “Typed Strings”
•  Units of measurement
•  …
•  Compact storage
•  On-stack allocaRons
•  SpecializaRon of collecRons (and other generic classes)
Type Classes (or Concepts)
•  Structural constraints
•  Non-intrusive
•  Extension-friendly

•  Type-level members (aka staRcs, companion objects)

•  Easier to Reify
More Safety
•  Immutable Data
•  The Holy Grail
•  Good for mulRthreading & OpRmizaRons
•  Pervasive in a type system

•  AnnotaRons for staRc safety

•  @ResultMustBeUsed
•  Extra guidance for type inference
•  Swip-like excepRon handling
ScripJng
•  JSR 223 supported

•  Already used
•  Gradle: Type-safe build scripts
•  Spring: Templates

•  Moving towards Data Science

•  REPL Improvements
•  Notebook integraRons
•  Libraries
Design and Development
On Mutual Support and Friendship
PragmaJc 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

CompaJbility Constraints
•  Both ways: for 1.X.X updates
•  Fixes
•  OpRmizaRons
•  Tooling features

•  Backward: for 1.X versions

•  Adding language features
•  Relaxing restricRons
•  Adding library APIs
Kinds of CompaJbility
•  Binary — Super-CriRcal
•  New binaries must work where old ones did
•  Run Rme
•  Compile Rme
•  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 Rmes (enum, assert)
CompaJbility 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
Waterfall or Agile?
☹ Waterfall
•  Design -> Implement -> Test -> Release
•  Ivory Tower

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

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

•  EAP builds – Early Access Preview

•  No compaRbility guarantees

•  Experimental features
•  Completely usable, but the design may change
•  Requires an explicit opt-in
•  We’ll try to minimize the migraRon pain
Possible Changes
•  Add a language feature/API
•  1.X only
•  Keep binary and source backward compaRble

•  Remove a feature/API
•  Definitely introduces an incompaRbility
•  DeprecaRon-Migrate-Remove cycle
What about legacy? Can we drop features?
•  Deprecate in 1.7
•  Provide automated migraRon
•  Elevate to error in 1.8
•  Provide a flag to demote back to warning
•  Keep automated migraRon
•  Delete in 2.0

WARNING: Use with care! Dropping features is painful for the users.
Experimental features
•  Design -> Implement -> Test -> Release With no Guarantees
•  Example: CorouRnes
•  Completely usable, but the design may change
•  Requires an explicit opt-in
•  We’ll try to minimize the migraRon pain

•  Similar to “from __future__ import feature”

•  Works for backward-compaRble changes too
What about legacy?
•  Systems accumulate legacy over Rme
•  Removing legacy => breaking compaRbility
•  MigraRon tools
•  DeprecaRon cycle
•  Can’t do this too open: a few years from now, if at all
Summary
•  Agility in design & development
•  Open design process: KEEP
•  Experimental features
•  DeprecaRon cycles
•  MigraRon tools

community
•  Kotlin ♥ You J