Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
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
• Kotli...
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, …
• ...
Kotlin/Native
• Technical Preview (Apr 2017)
• No VM
• Our own memory management
• Direct C interop
• Standalone executabl...
Plans & Vision
Strategic directions for Kotlin
The Two “Dimensions”
OOP
Functional
Scripting
Coroutines
Metaprogramming
JVM/Android JavaScript Native Multiplatform
F
v 1...
Platforms
JVM -> JS -> Native -> Multiplatform
Multiplatform Projects & Libraries
Common Module Common API & Impls
Headers without Impl
header
JVM Module
impl
JS Module ...
Vision: Full-Stack Applications
Everything testable can be shared!
Server
(JVM or Native)
Android Client
iOS Client
Web Cl...
Possible Products
• Cross-platform mobile: iOS/Android
• All testable code can be shared (MVVM could help along)
• Cross-p...
Paradigms
OOP -> FP -> Scripting -> Coroutines -> Metaprogramming
Coroutines
• Almost-free threads
• Straightforward asynchrony
• On all platforms
• JVM & JS: already supported
• Native: W...
Example: 100’000 Coroutines
val jobs = List(100_000) {
async(CommonPool) {
delay(1000L)
1
}
}
println(
jobs.sumBy { it.awa...
Going Meta
Future metaprogramming features of Kotlin
Traditional Approaches to Metaprogramming
• Reflection
• Annotation processing (Java)
• Expression trees (C#)
• Bytecode p...
Jedi Metaprogramming
• Macros
• Compiler runs some of your code
• Multi-stage languages
• You don’t want to know 
How do ...
The Kotlin Way: No Macros
• Plugins for Compiler/IDE
• Uniform API, must support IDE features
• Supersedes Annotation Proc...
The Kotlin Way: Other
• Common “bytecode” (for all platforms)
• Expression trees & compiler-as-a-service
• Source location...
To Infinity and Beyond
Other Language Enhancements
Some more plans
• Value Types & Inline Classes
• Compact storage, newtype, return several things from a function…
• Type C...
Immediate Future: Kotlin 1.2
• Focus on maintenance
• Performance is a priority
• Bugfixes, infrastructure, some tooling i...
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
• N...
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 ve...
Kinds of Compatibility
• Binary — Super-Critical
• New binaries must work where old ones did
• Run time — required
• Compi...
Compatibility Modes
• $ kotlinc -language-version 1.0 -api-version 1.0
• Turn off new features
• Every feature has an inte...
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...
How agile can
language
development
be?
Compatibility vs Innovation
Waterfall or Agile?
☹Waterfall
• Design -> Implement -> Test -> Release
• Ivory Tower
☺Agile
• Design -> Prototype -> Get ...
How agile can we be?
• Open design process
• KEEP = Kotlin Enhancement & Evolution Process
• EAP builds – Early Access Pre...
Summary
• Agility in design & development
• Open design process: KEEP
• Experimental features
• Deprecation cycles
• Migra...
Upcoming SlideShare
Loading in …5
×

Future of Kotlin - How agile can language development be?

3,779 views

Published on

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-

Published in: Software
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Future of Kotlin - How agile can language development be?

  1. 1. The Future of Kotlin How agile can language development be? Andrey Breslav
  2. 2. Disclaimer: Talking About the Future • We are planning things • We are not promising anything
  3. 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. 4. Where we are As of Kotlin 1.1, early 2017
  5. 5. Our creed • Pragmatic Language for Industry • Interop • Tooling • Safety • For JVM, JS and Native platforms
  6. 6. Kotlin/JVM • Age ≈ 1 year old • Approx. 160’000 users
  7. 7. Kotlin/JVM: Some Users… & the Big Banks
  8. 8. Server/Android = 50/50
  9. 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. 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. 11. Plans & Vision Strategic directions for Kotlin
  12. 12. The Two “Dimensions” OOP Functional Scripting Coroutines Metaprogramming JVM/Android JavaScript Native Multiplatform F v 1.1 Platforms Paradigms
  13. 13. Platforms JVM -> JS -> Native -> Multiplatform
  14. 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. 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. 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. 17. Paradigms OOP -> FP -> Scripting -> Coroutines -> Metaprogramming
  18. 18. Coroutines • Almost-free threads • Straightforward asynchrony • On all platforms • JVM & JS: already supported • Native: WIP
  19. 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. 20. Going Meta Future metaprogramming features of Kotlin
  21. 21. Traditional Approaches to Metaprogramming • Reflection • Annotation processing (Java) • Expression trees (C#) • Bytecode processing/instrumentation
  22. 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. 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. 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. 25. To Infinity and Beyond Other Language Enhancements
  26. 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. 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. 28. Design and Development On Managing Legacy, Love and Friendship
  29. 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. 30. Kotlin’s new today, but we look ahead Legacy 
  31. 31. Can we just drop it?
  32. 32. Users won’t like it…
  33. 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. 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. 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. 36. So, can we drop legacy features?
  37. 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. 38. How agile can language development be? Compatibility vs Innovation
  39. 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. 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. 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

×