Skip to content
0:00 / 0:00

#typesystem#typeinference#uniontypes

Revamping and Extending Kotlin's Type System | Ross Tate

Kotlin by JetBrains

100K subscribers • 61 videos on Hallway

YouTube
  • Recommended by 1 person: 1 in engineering communities.
  • Presented by Ross Tate
  • Made by the vendor. The company whose product it covers made or sponsored it.

Advanced. Deep dive for people who know the field.

12K views2 years ago1 recommendation

Programming languagesComputer scienceKotlinLanguage design and type systemsCompilers and interpreters

Ross Tate explains the unsoundness and complexity of Kotlin's type system and proposes ways to safely extend it with union and intersection types.

Recording brought to you by American Express. americanexpress.io/kotlin-jobs Enjoyed this talk? Experience it live at KotlinConf 2025—the biggest in history! Grab your tickets now: kotl.in/kotlinconf25 You might be surprised to learn that Kotlin's type system is undecidable and unsound; we can reliably cause the type-checker to stack-overflow, and we can trick it into thinking a String object is an Int. And that's before considering type inference or advanced features like platform types. Yet, understandably, developers are always requesting more features, like union and intersection types, and the Kotlin team would like to provide such features, but without jumping off a cliff of unrecoverable complexity. So how can we achieve this? Kotlin is not alone in these issues; in fact, I discovered many of these problems in Java first. Yet, in discovering them, I also recognized how unnatural these problematic programs were. That is, they do not seem to be programs any pragmatic person would actually write. Rather, they represented expressiveness in the language that no one actually seems to need but yet manages to complicate the typing algorithms and even the language design. Recently, the Kotlin team and I started to explore how we might remove the unnecessarily problematic expressiveness—in a way that no practical developer would ever notice—so that we can lay a better foundation for supporting the features the developers actually want. In this session, I will offer a sneak peek into the changes we are exploring: the pragmatic restrictions, the new algorithmic foundations, and the extensions like efficient unions and intersections we hope to add. While this is a long-term project, we hope this session will convey the design strategy we are pursuing, as well as provide an opportunity for developers to share feedback and insights that can help us ensure the improvements serve their needs over the coming years. #kotlinconf #kotlin

Why it's here

1 person recommends this

What people say. Included in a popular list of the best Kotlin talks of 2024.

u/TechTalksWeeklyin r/Kotlin • Recommends

All Kotlin talks of 2024 sorted by popularity Hi r/Kotlin! As part of Tech Talks Weekly, I've compiled a complete list of all Kotlin talks of 2024 and ordered it by the view count. The list contains 100 talks presented at (almost) all dev conferences this year. There's lots of really good content around new language features, coroutines, Functional Programming, Kotlin Notebooks and Dataframes and much more, so I highly recommend going thorugh the entire list. Let me know what you think! 1. **"KotlinConf'24 - Keynote"** ⸱ **+56k views** ⸱ 23 May 2024 ⸱ 00h 56m 47s 2. **"Kotlin Language Features in 2.0 and Beyond - Michail Zarečenskij"** ⸱ **+21k views** ⸱ 17 Jun 2024 ⸱ 00h 46m 57s 3. […

u/Skaldebanein r/Kotlin • Mentions

On “The buauty of Kotlin's type system”

Agree with your points! Regarding Java interop, that's getting better from the Java side (finally they settled on a single unified `@NonNull`/`@Nullable` annotation standard)! And I honestly find myself barely touching Java APIs directly with the wealth of Kotlin-first libraries these days. Haven't seen an NPE for months (unless I asked for it `!!` :p). And indeed while the technical meaning of \`null\` and \`Option.None\` is the same, the *actual usage* is quite different, and `null` is currently used in Kotlin to represent errors (due to `Result` not being very ergonomic), in case you wanted to avoid `Exceptions` (which aren't great either). However, they're working on fixing that too!…

u/mzarechenskiyKotlin-teamin r/Kotlin • Mentions

On “Kotlin Ecosystem AMA – December 11 (3–7 pm CET)”

Speaking of union and intersection types: in the current type system, it’s not possible to implement them in a way that is both convenient to use and allows the compiler to maintain polynomial-time type checking. So instead, we’re following two tracks: ongoing type-system research by Ross Tate, which aims to make the type system more expressive (see Ross’s KotlinConf talk: [video and a separate track focused on addressing specific use cases. In particular, we see that union types can be very useful for error handling, and for that we’re exploring “rich errors” (https://github.com/Kotlin/KEEP/discussions/447)

u/okarmazinin r/Kotlin • Mentions

On “Kotlin Roadmap Update: Find out what comes next for Kotlin”

Here's the recently published kotlinconf video about this. link to this video

u/Ceigeyin r/Kotlin • Mentions

On “The buauty of Kotlin's type system”

Well (before getting hopes up 😅) it’s specifically just for errors and it’s in the early internal development stage. Also note that I’m sort of assuming if sealed classes aren’t your cup of tea for tagged unions then you’re after untagged unions, but I could totally be misunderstanding what you’re after link to this video