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