I would say that the primary interest in building the type system is in supporting a better developer experience, both in terms of productivity (better autocomplete, go-to definition, etc.) and in terms of correctness (identifying bugs earlier, which is why we're actively concerned with having a _sound_ type system). There's a pretty limited surface of areas where we accept unsoundness today (outside of casting) and they're all connected to limitations of the type system that we've been working to resolve.

Longer-term, there's definitely some interest in how we could leverage types to support more optimized code, but it's been a notoriously difficult problem for gradually-typed languages in general, see [Is sound gradual typing dead?](https://dl.acm.org/doi/pdf/10.1145/2837614.2837630)

Gotcha. For some reason I was under the impression that getting perf from gradual typing had been a goal of y'all's.

> primary interest in building the type system is in supporting a better developer experience

Yeah this is the right reason to do it :-)

> there's definitely some interest in how we could leverage types to support more optimized code, but it's been a notoriously difficult problem for gradually-typed languages in general

I know. I still get folks asking why TypeScript types can't be used to make JS fast and it's quite exhausting to explain this.

Hard to imagine gradual types beating what you get from the combo of PICs, speculative JITing, and static analysis.

(I worked on JavaScriptCore's optimizer, hence why I'm curious about where y'all are coming from on this)