Skip to content
0:00 / 0:00

#typescript#structuraltyping

"Understanding TypeScript's Structural Type System" by Drew Colthorp

Strange Loop Conference

88K subscribers • 110 videos on Hallway • Conference channel

YouTube
  • Recommended by 1 person: 1 in engineering communities.
  • Presented by Drew Colthorp

Intermediate. Assumes working knowledge.

15K views8 years ago1 recommendation

Programming languagesTypeScriptLanguage design and type systems

Drew Colthorp explains how TypeScript's structural type system differs from nominal systems and how it fits JavaScript.

I was wrong. I thought TypeScript was something like a Java-ey type system layered atop JavaScript, bringing a dose of brittleness and losing the flexibility I appreciated about the warty-yet-ubiquitous multi-paradigm language. But that's not it at all! TypeScript radically improves the JavaScript development experience by providing a flexible, light-weight type system for modern EcmaScript. It does so while maintaining a delicate balance: adding a way to enforce assumptions and invariants without removing the flexibility prized by dynamic language developers. This works because TypeScript's type system is structural and not nominal - that is, based on shapes of data instead of identities of types. Come see what's cool and exciting about TypeScript's defining feature. We'll show what differentiates a structural type system from a nominal one; how key features of TypeScript provide a powerful language to express invariants about your system; and how TypeScript leverages its knowledge of what code implies about the shapes of data to avoid most of the type system nuisances that put some developers off of statically typed languages. Drew Colthorp

Why it's here

1 person recommends this

What people say. Recommended as an excellent explanation of structural typing in TypeScript.

u/gavrehin r/typescript • Recommends

Understanding TypeScript's Structural Type System

u/oilshellin r/ProgrammingLanguages • Mentions

On “Do any languages have novel ways to represent data?”

You might be interested in this thread: https://www.reddit.com/r/ProgrammingLanguages/comments/a5g2t4/why_case_classes_are_better_than_variant_types/ That was another problem I found with the "simple" problem of representing a programming language with static types. To me, it's ironic that ML was designed to represent languages, and works very well for toy/mathematical ones, but falls down a bit once it hits the "real world"... OCaml seems to have developed many mechanisms to cope with these "real world" problems, but I would rather not have so many mechanisms in a language. ---- Right now I idly wonder whether having an extremely simple dynamic data model, and then optional typing lik…