A successful project usually grows, and Kotlin is no exception. We are adding new targets (JavaScript and Native) and new computation models (coroutines). This talk is about our vision of the future of Kotlin as a language and a ecosystem. We'll talk strategy: what we think our industry needs at large and how we are going to fit Kotlin into this picture. We'll talk tactics: how we deal with legacy and compatibility issues, and whether there will ever be Kotlin 2.0. We'll talk operations: can we do “continuous delivery” for language features? Or, more generally, how agile can language development be? https://mixitconf.org/en/2017/the-future-of-kotlin-how-agile-can-language-development-be-

1. The Future of
Kotlin
How agile can language development be?
Andrey Breslav

2. Disclaimer: Talking About the Future
• We are planning things
• We are not promising anything

3. Outline: The Future of Kotlin
• Where we are today
• Our plans and vision
• How we work
• Our constraints
• Legacy
• Kotlin Loves You 
• Q&A
c o m m u n i t y

4. Where we are
As of Kotlin 1.1, early 2017

5. Our creed
• Pragmatic Language for Industry
• Interop
• Tooling
• Safety
• For JVM, JS and Native platforms

6. Kotlin/JVM
• Age ≈ 1 year old
• Approx. 160’000 users

7. Kotlin/JVM: Some Users…
& the Big Banks

8. Server/Android = 50/50

9. Kotlin/JS
• Since Kotlin 1.1 (Feb 2017)
• JS Interop
• Dynamic types
• ts2kt + DefinitelyTyped
• React, webpack, npm, …
• Full-stack projects
• Common libraries
• Shared code

10. 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

11. Plans & Vision
Strategic directions for Kotlin

12. The Two “Dimensions”
OOP
Functional
Scripting
Coroutines
Metaprogramming
JVM/Android JavaScript Native Multiplatform
F
v 1.1
Platforms
Paradigms

13. Platforms
JVM -> JS -> Native -> Multiplatform

14. Multiplatform Projects & Libraries
Common Module Common API & Impls
Headers without Impl
header
JVM Module
impl
JS Module iOS Module
impl impl
Platform API & Impls
• Common module:
• header fun foo()
• Platform module:
• impl fun foo() { ... }

15. Vision: Full-Stack Applications
Everything testable can be shared!
Server
(JVM or Native)
Android Client
iOS Client
Web Client
(JS/WASM)
Desktop Client
(JVM or Native)

16. 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

17. Paradigms
OOP -> FP -> Scripting -> Coroutines -> Metaprogramming

18. Coroutines
• Almost-free threads
• Straightforward asynchrony
• On all platforms
• JVM & JS: already supported
• Native: WIP

19. Example: 100’000 Coroutines
val jobs = List(100_000) {
async(CommonPool) {
delay(1000L)
1
}
}
println(
jobs.sumBy { it.await() }
)
Can’t be done
with threads:
OutOfMemoryError

20. Going Meta
Future metaprogramming features of Kotlin

21. Traditional Approaches to Metaprogramming
• Reflection
• Annotation processing (Java)
• Expression trees (C#)
• Bytecode processing/instrumentation

22. Jedi Metaprogramming
• Macros
• Compiler runs some of your code
• Multi-stage languages
• You don’t want to know 
How do I make
an IDE now?

23. 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

24. 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

25. To Infinity and Beyond
Other Language Enhancements

26. 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, ...

27. Immediate Future: Kotlin 1.2
• Focus on maintenance
• Performance is a priority
• Bugfixes, infrastructure, some tooling improvements
• One major feature:
• Java 9 Support

28. Design and Development
On Managing Legacy, Love and Friendship

29. 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

30. Kotlin’s new today, but we look ahead
Legacy 

31. Can we just drop it?

32. Users won’t like it…

33. 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

34. 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)

35. 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

36. So, can we drop legacy features?

37. 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.

38. How agile can
language
development
be?
Compatibility vs Innovation

39. Waterfall or Agile?
☹Waterfall
• Design -> Implement -> Test -> Release
• Ivory Tower
☺Agile
• Design -> Prototype -> Get Feedback -> Redesign
• What about compatibility?
c o m m u n i t y

40. 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

41. Summary
• Agility in design & development
• Open design process: KEEP
• Experimental features
• Deprecation cycles
• Migration tools
• Kotlin ♥ You 
c o m m u n i t y