Scribd
Upload
44 views

The Future of Kotlin: How Agile Can Language Development Be?

Kotlin is a pragmatic language for industry that aims to balance compatibility with innovation to allow for agile development. It is currently supported on the JVM, JavaScript, and as a technical preview for native platforms. The team plans to expand support for multiplatform projects, functional programming paradigms like coroutines, and eventually metaprogramming capabilities. To manage compatibility while continuing to evolve the language, they employ strategies like deprecation cycles, experimental features, and community feedback processes.

Uploaded by

Saad Shafiq
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
44 views

The Future of Kotlin: How Agile Can Language Development Be?

Kotlin is a pragmatic language for industry that aims to balance compatibility with innovation to allow for agile development. It is currently supported on the JVM, JavaScript, and as a technical preview for native platforms. The team plans to expand support for multiplatform projects, functional programming paradigms like coroutines, and eventually metaprogramming capabilities. To manage compatibility while continuing to evolve the language, they employ strategies like deprecation cycles, experimental features, and community feedback processes.

Uploaded by

Saad Shafiq
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 41

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
• Kotlin Loves You  community
• Q&A
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, …

• Full-stack projects
• Common libraries
• Shared code
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
Plans & Vision
Strategic directions for Kotlin
The Two “Dimensions”
Paradigms

Metaprogramming

F
Coroutines
v 1.1

Scripting

Functional

OOP
Platforms

JVM/Android JavaScript Native Multiplatform


Platforms
JVM -> JS -> Native -> Multiplatform
Multiplatform Projects & Libraries
• Common module:
• header fun foo()

Common Module Common API & Impls


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

impl impl impl


JVM Module JS Module iOS Module

Platform API & Impls


Vision: Full-Stack Applications

Web Client
Android Client
(JS/WASM)

Server
(JVM or Native)

Desktop Client
iOS Client
(JVM or Native)

Everything testable can be shared!


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
Paradigms
OOP -> FP -> Scripting -> Coroutines -> Metaprogramming
Coroutines
• Almost-free threads

• Straightforward asynchrony

• On all platforms
• JVM & JS: already supported
• Native: WIP
Example: 100’000 Coroutines
val jobs = List(100_000) {
async(CommonPool) {
delay(1000L)
1 Can’t be done
} with threads:
}
OutOfMemoryError
println(
jobs.sumBy { it.await() }
)
Going Meta
Future metaprogramming features of Kotlin
Traditional Approaches to Metaprogramming
• Reflection

• Annotation processing (Java)

• Expression trees (C#)

• Bytecode processing/instrumentation
Jedi Metaprogramming
• Macros
• Compiler runs some of your code

• Multi-stage languages
How do I make
• You don’t want to
an know 
IDE now?
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
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
To Infinity and Beyond
Other Language Enhancements
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, ...
Immediate Future: Kotlin 1.2
• Focus on maintenance
• Performance is a priority
• Bugfixes, infrastructure, some tooling improvements

• One major feature:


• Java 9 Support
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

• Not a research experiment

• More than a compiler: IDEs, Build tools, etc


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 versions


• Adding language features
• Relaxing restrictions
• Adding library APIs
• Old code must work
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)
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
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 flag to demote back to warning
• Keep automated migration

• Delete in 2.0

WARNING: Use with care! Dropping features is painful for the users.
How agile can
language
development
be?
Compatibility vs Innovation
Waterfall or Agile?
☹Waterfall
• Design -> Implement -> Test -> Release
• Ivory Tower

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

community
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
Summary
• Agility in design & development
• Open design process: KEEP
• Experimental features
• Deprecation cycles
• Migration tools

community
• Kotlin ♥ You 

You might also like