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()
• PlaWorm module: • impl fun foo() { ... }
impl
JVM Module
Common Module header
impl
JS Module
PlaWorm API & Impls
Common API & Impls Headers without Impl
impl
iOS Module
Vision: Full-Stack ApplicaJons Web Client (JS/WASM)
Android Client Server (JVM or NaRve)
Desktop Client (JVM or NaRve)
iOS Client
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 How do I make • MulR-stage languages 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
• Kotlin ♥ You J
community
