The programming language after Kotlin – with the creator of Kotlin

Summary of The programming language after Kotlin – with the creator of Kotlin

by Gergely Orosz

1h 44m•February 12, 2026
Listen to Episode

Overview of The programming language after Kotlin – with the creator of Kotlin

Host Gergely Orosz interviews Andrei (Andrey) Breslav, the creator of Kotlin. The conversation covers Kotlin’s origin story, design trade-offs and influences (Scala, C#, Groovy, Gosu), the enormous engineering work to interoperate with Java, how Android adoption exploded after Google’s endorsement, and Andrei’s current work on Codespeak — a new English-based programming language idea built around LLMs and preserving developer intent in a world of AI-assisted coding.

Key topics covered

  • Why JetBrains created a new JVM language in 2010 and the goals behind Kotlin
  • Concrete design decisions, inspirations and regret (no ternary operator, multiple inheritance discarded)
  • How Kotlin achieved deep Java interoperability and the engineering challenges involved
  • The adoption curve and the role Google/Android played in Kotlin’s growth
  • Development process, release cadence, compatibility strategy and tooling-first approach
  • Andrei’s post-Kotlin work: Codespeak — programming with English + LLMs
  • Practical impacts of AI on software engineering and advice for developers

Background & origin story

  • JetBrains wanted a pragmatic, statically-typed language to modernize Java for large projects (2010).
  • Andrei joined after academic work on DSLs; early design was whiteboard-heavy and extremely pragmatic.
  • Initial approach: IDE-first (IntelliJ plugin) to rapidly prototype syntax and tooling; later a full compiler and multiple backends (JVM, JS, Native, Wasm).
  • Early internal name: “Jet”; final name “Kotlin” came from a local island — chosen partly for being Googleable and unclaimed.

Kotlin design choices and influences

  • Slogan: “A pragmatic language for industry” — favor familiarity and proven ideas over academic novelty.
  • Major language goals:
    • Reduce boilerplate (type inference, properties, less ceremony).
    • Improve readability (reading code prioritized over writing it).
    • Static typing for large-scale codebases.
  • Key features and influences:
    • Null-safety (one of the most important differentiators).
    • Extension functions (inspired by C#).
    • Typed builders / dangling lambdas inspired by Groovy.
    • SmartCasts (inspired by Gosu) — infers safe casts after checks.
    • Many ideas borrowed and adapted from Scala (constructors, vals/vars, generics) and C# (generic syntax handling).
  • Things intentionally left out or postponed:
    • Full pattern matching (deferred because it’s large; when combined with smartcasts/destructuring it already covers many cases).
    • Multiple inheritance (abandoned due to complexity).
    • Ternary operator: omitted because Kotlin made if an expression; Andrei admits this omission is now a regret — it would have been pragmatic to include it.

Java interoperability — the engineering headache and solutions

  • Interop was a top priority: Kotlin must call Java libraries and Java must call Kotlin code in mixed projects.
  • Practical strategy:
    • Compile Kotlin first into JVM bytecode so Java compilers see binaries they can consume.
    • Kotlin includes a Java front-end to resolve Java sources during Kotlin compilation.
  • Hard problems and tricks:
    • Nullable types: Java has no compile-time nullability. Treating all Java types as nullable initially proved unusable. Kotlin devised a hybrid solution (annotations, conservative/widening heuristics, and a special type calculus) to make Java types usable without exploding null-check verbosity.
    • Collections: Java collections are mutable and invariant. Kotlin exposes read-only views and uses compiler/hacking-layer tricks to present nicer types to Kotlin while remaining compatible with Java.
    • Incremental compilation across two languages, binary compatibility, and special “message from the future” bytes to let older compilers understand newer binaries.
  • Result: seamless developer experience but required massive engineering, migration tooling, compatibility management and careful deprecation cycles.

Tooling, process and release history

  • IDE-first development (IntelliJ) allowed rapid syntax iteration and good initial tooling.
  • Timeline:
    • Started autumn 2010; initial prototype and months of whiteboard design.
    • Public 1.0 release: February 2016 (≈5 years of work).
    • Team growth: a few part-timers → ~25 by 1.0 → ~100 by 2020 (≈70 engineers).
  • Practices and lessons:
    • Early and public issue tracker; migration tools for breaking changes; experimental features behind explicit flags.
    • Bootstrapping complexities (compilers written in their own language) required hacks to move the language forward.
    • Compatibility was a major focus—Kotlin delayed 1.0 to reduce breaking changes and provide migration utilities.

Kotlin adoption and Android’s role

  • Initial target audience: server-side Java developers (Spring etc.) and desktop Java users.
  • Android adoption was not the original plan but became pivotal:
    • Android’s fragmented (often old) Java ecosystem created demand for a nicer language that didn’t rely on platform Java upgrades.
    • Kotlin’s IntelliJ-based tooling fit well with Android Studio (since Android moved from Eclipse to IntelliJ).
    • Google announced official Kotlin support at Google I/O 2017 — a surprise to JetBrains but a watershed moment that sharply increased adoption (from tens of thousands to millions).
  • Legal/organizational notes:
    • Google temporarily held the Kotlin trademark during foundation setup.
    • Kotlin Foundation later established to manage governance.

Codespeak — the next language idea (Andrei’s current project)

  • Motivation: With LLMs, many implementation details can be inferred by models from high-level intent. This enables the next jump in abstraction: languages that let you communicate intent in English (or near-English) and have LLMs generate working code.
  • What Codespeak aims to be:
    • A programming language based on English (informal + formal parts), built to work with LLMs as a primary “library” or resource.
    • A language designed to reduce noise/boilerplate and preserve human intent as a first-class artifact (so conversations with agents aren’t lost).
    • Emphasis on making test generation and verification integral (tests that prove intent).
  • Design challenges:
    • LLMs perform best on well-represented languages; a brand new formal language lacks training data.
    • Extracting compact, stable English specifications that map to implementation and that evolve nicely with commits.
    • Balancing informality (natural language queries) with safety, verifiability, and reproducibility.
  • Philosophical stance: Codespeak is for humans-in-charge, not for replacing human decision-making (Andrei rejects the notion of a singularity where models make all decisions).

How AI/LLMs are changing software engineering (Andrei’s view)

  • Immediate changes:
    • Coding agents and autocompletions drastically increase productivity; tools (Cursor, GitHub Copilot, IDE integrations) are improving fast.
    • The conversation with agents (human intent) often disappears once code is committed — creating a missing intent layer between author and collaborators.
    • Tests and verification are growing in importance; teams will rely more on automated verification than manual code review in some contexts.
  • Near-term tooling needs:
    • Integrating agents with code-aware tools (language servers, indexers) rather than raw token-based cloud prompts.
    • Development environments built around agents (better UX than simple terminals).
    • Improved review tools geared for AI-generated code and tests that better express intent.
  • Advice to engineers:
    • Learn to use AI tools skillfully — there’s real skill in prompting and verification.
    • Invest in testing and verification workflows; tests become central when code is AI-generated.
    • Either master depth (low-level systems expertise) or learn to be extremely productive with higher-level tooling; both paths remain valuable.

Actionable takeaways for listeners

  • If you’re a developer:
    • Start experimenting with AI coding tools and integrate them into your workflow (but keep rigorous tests and verification).
    • Learn Kotlin basics (null-safety, extension functions, smartcasts) if you work on JVM/Android — its ergonomics are widely valued.
    • Focus either on deep systems understanding (rare expertise) or on becoming highly effective with new agent-driven tooling.
  • If you manage teams:
    • Invest in tests, automated verification, and developer tools that expose intent and make agent outputs auditable.
    • Don’t assume agents remove the need for juniors or teams — they change the nature of work and create new tooling/verification needs.

Notable quotes & short insights

  • “The whole art of making a good language was to restrict the user in a good way.” — On balancing power and simplicity.
  • “If someone offers you a job to create a system that interoperates transparently with another huge system you don't control, ask for a lot of money.” — On the difficulty of Java interop.
  • “You communicate with the machine in human language, but with your teammates in code — that conversation disappears. We’re missing an intent layer.” — The core motivation behind Codespeak.

Quick personal notes from Andrei (fun/rapid items)

  • Favorite small tools: AirPods and earmuffs.
  • Book recommendation: Zen and the Art of Motorcycle Maintenance — for its blend of technology, philosophy and narrative.

Final summary

  • Kotlin succeeded because it was pragmatic: it borrowed proven ideas, prioritized tooling and interop, and solved everyday pain points (nulls, boilerplate, ergonomics) for large teams.
  • Creating a language is an engineering and social project: IDEs, compilers, migration tooling, compatibility rules, and platform partnerships are as important as syntax.
  • The AI era opens a new frontier: languages and tooling that treat human intent as first-class, leveraging LLMs while preserving verifiability and team collaboration. Codespeak is Andrei’s attempt at that next layer.
  • Practical next steps for engineers: adopt AI tools thoughtfully, double down on tests/verification, and keep learning (either depth or productive higher-level practices).

If you want concise cheat-sheet points (e.g., Kotlin features to learn first or practical prompts for AI-assisted coding), say which one and I’ll give a focused list.