Comparing TypeScript and Elm's Type Systems

Comparing TypeScript and Elm's Type Systems

TypeScript and Elm have very different type systems with different goals. We dive into the different features and the philosophy behind their different designs.

PublishedOctober 25, 2021

Episode#42

TypeScript and Elm have different goals
Soundness is not a goal of the TypeScript type system
TypeScript Design Goals (and non-goals)
TypeScript's any type
Nominal vs structural typing

TypeScript's `any` vs. Elm's `Debug.todo`

TypeScript's any essentially "turns off" type checking in areas that any passes through.

In Elm:

You can get a type that could be anything with Debug.todo, but you can't build your app with --optimize if it has Debug.todo's in it
You will still get contradictions between inconsistent uses of a type that could be anything (see this Ellie example)

This Ellie example (with compiler error as expected) and this TypeScript playground example (with no error) show the difference.

any can not be used in places that take never
any vs unknown
JSON.parse returns any, as do many core and published typings
io-ts lets you validate JSON similar to JSON decoders in Elm
Definitely Typed (published type definitions for NPM packages)
Definitely Typed search
noImplicitAny
TypeScript `strict mode in tsconfig
Dillon's post TypeScript's Blind Spots
JS semantics allow types that may not be intended (like adding a string + object, '' + {} === '[object Object]')
Function parameters are inferred to be any regardless of implementation if they aren't given an explicit type
Type narrowing
TypeScript has untagged unions (just called Unions) - in Elm, there are only tagged unions (called Custom Types)
Undefined vs null
TypeScript's Void type
TypeScript doesn't have checked exceptions like Java (there is a discussion about this on GitHub) - Elm only has explicit errors as data that must be handled exhaustively like other data types
Discriminated unions vs Elm custom types
Literal types
TypeScript allows number literal values, but arithemtic expressions return generic number values instead of literal types
Enums
Branded types in TypeScript vs opaque types
Elm Radio Opaque Types episode
Switch statements are not exhaustive - you can add an eslint rule to check that (or the never trick, assert unreachable)
Key of operator in TypeScript
TypeScript's type system can do some cool things that Elm can't (for better and for worse)
Prisma
Prisma advanced TS meetup talks
Tuples in TypeScript are just arrays and use narrowing - Tuple in Elm is a specific type
elm-ts-interop
TypeScript handbook on official site

Transcript

So, what are we talking about today?

Today we're talking about TypeScript again, and we'll be comparing it with Elm.

But since comparing the two is a very big topic, we were considering just looking at

the type systems.

I think that's enough for an episode.

So let's sort of clarify something.

What do we want listeners to take away from this?

Because I want to state that our goal is not to pick a winner, right?

For one thing, we're far too biased to be trusted with such a thing.

We're just laying out some facts.

But also, I'm a big fan of this idea of not being an absolutist about which things are

So it's far more useful to look at what are the goals, what are these tools best suited

for, and let's understand the design choices that make them well suited for these types

And I think that is very much the way that I think about the TypeScript versus the Elm

type systems is TypeScript...

I've said this before on the podcast.

To me, TypeScript is extremely elegantly designed to solve the exact problem it solves, which

is Elm is extremely elegantly designed to solve the problem it solves.

And they solve two very different problems.

So Jeroen, I promised you a quote, which we both agreed was better to save for on air

rather than reading it on the pre call.

I'm so excited to finally listen to it.

Yes, now that we've gotten your expectations high, here you go.

So this is from a GitHub issue in the TypeScript repo.

And someone is asking the question, what I'm interested in knowing is whether the TypeScript

community slash team consider type checking unsoundness as something that should be fixed.

And a TypeScript core team member is saying, just speaking specifically to this point,

100% soundness is not a design goal.

Soundness, usability and complexity form a trade off triangle.

There's no such thing as a sound, simple, useful type system.

Now, I'm not sure I agree with that last point, unless it's specifically within the context

of what TypeScript is doing, which is adding types within the semantics of JavaScript,

and within the ecosystem of existing JavaScript code.

In that case, yes, I think that's true.

But in the broader sense, I think that Elm gives a pretty good case that you can have

a sound, simple and useful type system, right?

Can you elaborate what you mean with soundness?

Or what they mean with soundness?

Yeah, well, I think soundness means, so like they give an example in this issue, which

I'll link to, you know, where they're adding something to an array.

And you know, you can kind of fool the type system.

So there are a number of ways that you can fool the type system in TypeScript.

But basically, like, I think Elm and TypeScript are working from two opposite ends.

Elm starts from everything must be proven, and is considered to be incorrect types until

I can guarantee it otherwise.

Like, unless I can convince myself that the types are correct, I'm going to reject it.

And TypeScript goes from the opposite side.

It says, I'm going to assume that this is a working application, unless I can find some

evidence that contradicts that.

So it's starting from, it's almost like, you know, innocent until proven guilty, or guilty

until proven innocent.

I think that Elm, in Elm, types are guilty until proven innocent.

And in TypeScript, they're innocent until proven guilty.

And that is because they're working on very different styles of code bases.

Like, Elm starts from scratch.

So if you only use the types that Elm has in its core libraries, and the compiler knows

about them and knows that it can give you those guarantees, then it's a good idea to

start with something that can be proven to be right.

Whereas with TypeScript, you start basically with the JavaScript code base.

Or at least that is how it is designed for.

I don't know if it still makes a lot of sense for projects that start with TypeScript.

But at least that's the original goal.

So you start with TypeScript, and you have no guarantees at all.

And then you try to prove things correct where you can, and show the errors where you cannot.

Where you can show the errors.

So if you're starting the idea of FFI, like foreign function interface, being able to

call directly into JavaScript, that is the big differentiator, right?

Because if you're starting with a fresh brand new code base, in Elm, you can't pollute the

sound typed environment where every type you have you know is correct.

You can't pollute that with unsoundness because you can't directly invoke unsound type systems.

But with TypeScript, the design decision, which I think makes perfect sense for TypeScript,

is sure, go ahead, call JavaScript all you want.

And oh, I've got some NPM library that doesn't have TypeScript typings?

We'll just help you out as much as we can around that, and we'll just consider the types

to be untyped there.

And we probably won't be able to help you much for that untyped code.

But we can for the rest of the application.

We can for the rest of the application.

So it's seen as sort of like a bonus, the types, rather than everything must be proven

and the entire ecosystem is designed around this, right?

Because you can just publish a new...

You can publish an NPM package that uses eval.

What type does it do?

TypeScript can't help you there.

It could eval a string from user input, and it could parse some JSON.

So these are the core design decisions that guide Elm versus TypeScript.

And I think this is what I hope people will come away from listening to this episode with,

is this understanding of the different design goals.

And take that for whatever purposes serve you.

If you're not an Elm developer, that helps you kind of think about where to be extra

careful when you're writing TypeScript code and how to think about these trade offs.

If you're not a TypeScript developer, if you only do Elm, and you need to use a little

bit of JavaScript, hopefully this helps you understand the design decisions and goals

behind Elm a little bit better.

So the TypeScript type system is, in my opinion, and I'm guessing yours as well, a lot more

complex than Elm's.

And partially the reason for that is because it needs to type check JavaScript.

And JavaScript can do a lot of things.

So if you want to have a type system that doesn't limit on what JavaScript can do, or

at least when it works, then you do need to have a very powerful type system.

So that's something to keep in mind.

Oh, it's very complex.

It can do a lot of things and that is potentially very hard to annotate in your types.

But it's there for a reason.

It's because JavaScript has a lot of features.

And also to further back up this idea that we're not trying to prove which type system

is better, but we're just looking at their design goals.

I think that TypeScript is a very cool type system and it has some features that I think

are really neat, which the Elm type system does not have.

Does that mean the Elm type system should have them?

Not necessarily.

They're just features that are very well suited to the specific problems that TypeScript is

solving and they're really cool and they're good to be aware of.

So for example, in Elm, if you change the value of a string, like if you change concrete

values within the same type, it will never change whether the types compile or give a

compiler error.

That will never happen.

Whereas in TypeScript, that can happen.

So TypeScript is able to actually look at concrete values, which the Elm type system

does not have the ability to do.

That gives you some really interesting capabilities.

If you're a TypeScript library author or application author.

So by the way, was the quote worth it your own?

It was worth it.

I think sometimes it's easy to sort of, TypeScript can be an easy target to be like, oh, TypeScript

isn't a sound type system.

But I think it's good to have primary sources to say, no, this is the stated design goal

This is not designed to be unsound.

And that's not a bad thing.

It's just a different goal and understand that.

And this is not my words.

This is the words of the TypeScript team.

I mean, it could try to, but then it would be a very different language and you would

have a lot more errors, I'm guessing.

Yeah, a lot more.

And one of the things they talk about is, you know, just the idea of mutation and how

like, how do you square mutation with sound types?

You know, is it possible?

Yes, but it's an added complication.

And it's not one that, that's, so we'll get into this later in the episode, but that's

one of the avenues of introducing unsoundness into TypeScript types.

Yeah, I guess one thing you could do is to, instead of being a superset of JavaScript,

is take a subset of JavaScript and add type annotations.

So remove mutations from JavaScript and then add types.

And then the language would be a lot simpler, but you can do a lot less things with it.

And it's not compatible with JavaScript libraries that are out there on NPM and stuff like that.

Yeah, yeah, absolutely.

Well, should we get to the basics a little bit?

That sounds good.

Where should we start?

How basic do we want to get here?

Well, I guess let's start with the primitives.

So TypeScript has three primitives.

It has strings, numbers, and Booleans, which Elm also has except for number because it

has int and floats.

Although secretly, it's actually just JavaScript numbers.

Everything is JavaScript under the hood.

So at least until it stops compiling to JavaScript only.

It's got those primitives.

If you haven't seen a TypeScript annotation before, you can take let name equals Yeroon

and you can turn that into something with a type annotation with let name colon string

But the TypeScript type system can also do type inference.

So you don't strictly need to put type annotations everywhere similar to Elm.

But it's probably a good idea.

It's probably done idiomatically.

It's done pretty much everywhere in idiomatic Elm code.

In my opinion, some people might have different opinions on that.

But in TypeScript it's not.

I wrote rules to add type annotations everywhere possible.

I use that rule often.

And actually, I used to not put type annotations on my let bindings in Elm.

But that rule sort of changed my thinking on that.

And now I just put them everywhere.

Because the more hints you can give to the compiler where you're like, no, no, this is

definitely the type.

I know this is the type I want here.

The more specific the compiler can be to pointing you to the problem if something goes wrong.

So that's how I think of it.

So, if you put a big blob of text about an error in Elm, if you don't put type annotations

where it's needed, because it will say something like, oh, this big record has this field that

is not the right type.

But if you put the annotation on a value that you put before and that it notices that it's

wrong over there, then it will point the error to a smaller section.

So the error messages are much better if you put type annotations.

And this I don't know about TypeScripts.

And I was wondering whether you know, are the error messages better when you put them

Do you have the same kind of problem you do in Elm?

I mean, I think that's just an inherent property of, you know, that you're saying, like, you're

giving more information for the type system to say, this is supposed to be this type.

And it needs to square everything with all that information.

So it's going to point the problem to somewhere else, as long as all those type annotations

So, yeah, I think that's the same as with Elm.

But idiomatically, I think in the TypeScript ecosystem, I think it's a lot more common

to just say, like, oh, wow, this type system is great.

I don't have to put annotations everywhere, which as an Elm developer, I tend to think

of it more as like, wow, this type system is great.

It's smart enough to figure things out.

And the tooling can help me put type annotations places to lock them in as I do my work so

that I can give it all the clues possible to help it give me better error messages.

But what I want is I want it to catch mistakes and point me to the problem so that when something

has a compiler error, it's the shortest path possible to fix things.

And I think that's just a different mindset between Elm and TypeScript.

I don't know if it's only for TypeScript.

So the last time I used Java was a very long time ago, like more than 10 years ago.

And when I was using it, you had to specify the type of everything, of every variable

And then later, they added the feature where you could say, val x equals blah, blah, blah,

where the compiler would infer the type.

So I'm guessing the compiler is still pretty strict.

So if it could not figure something out, it would tell you.

But since everything has annotations everywhere, I'm guessing it's pretty good at that.

But still, yeah, when I put type annotations on let variables, it's partially for documentation.

So that I don't have to, if I say something like x equals function call, then I don't

want to have to look to the function definition to know what the type of my result is, especially

if it contains something like generics, where then I would also have to check for the arguments.

And that can be a rabbit hole.

But if I put a type annotation in there, and the type of the function call changes, I kind

of want to know.

Because that will change how I respond where I assign the variable.

That's a great point.

You don't want to be like trying to fix things and then without realizing it, change the

type of a variable in your let bindings.

I mean, it will probably give an error somewhere else.

But if you're in the middle of a challenging type puzzle that you're solving, and you didn't

realize then, yeah, you want to have put those as fixed points.

So you can change one small thing at a time when you're trying to solve a problem.

Then I'm guessing in TypeScript, it can be dangerous because if the function call somehow

starts returning any compared to something else before, now you have polluted your function

So I know we were supposed to talk about basics, but let's talk about any.

So there are several points that just came up there.

I want to touch on one thing quickly, which is you mentioned like Java and the explicitness

and verbosity of Java types.

I think to some extent like that, that's what a lot of people push back on when they're

against typed languages.

I think a lot of that came from a lot of these design decisions of Java.

So there were many places where you would write duplicate information and you would

define a type and then you would invoke a constructor and you'd have to put the type

again and it seemed like repetitive information and this sort of thing.

Like one of the things that a lot of people had trouble with Java is that almost everything

is like a nominal type in Java rather than a structural type.

So a nominal type being nominal as in name, nom, nom, if you prefer.

That is basically saying that if it doesn't refer to the specific identifier of like a

constructor, then it's not the same thing, which in Elm that would be like a custom type.

If you'd find a custom type in a particular module, if that custom type has a value of

a particular record type inside of the constructor of the custom type variant, then it doesn't

matter if you create something that has the same record with the same fields.

It didn't use that identifier as the constructor to construct that variant and therefore it's

And so you can do that in Elm.

In Java, it's almost like everything is that.

You can create these like map like structures and array lists and things like that.

But even those are like a data structure that is nominally typed and can have key value

pairs if you want or whatever.

But you can't sort of just put a key value data structure and then, oh, okay, now I see

it has these fields with these types.

And so TypeScript has that and Elm has that.

It turns out that's very nice because sometimes you're like, I don't care how it was constructed.

I just need these values or maybe even a subset of these values like extensible records in

I need a record and I don't care what other data it has, but I need a first name and a

last name to be strings.

And that's all I care about.

So the annoying part in Java is that you can't have anonymous records basically.

You would have to have a first last name interface or class or thing like that.

And something would, you'd have to say implements first last name or, you know, and that people

get really tired of that with Java.

And I feel like that's what a lot of the pushback against typed languages came from.

And then people get into a language like Elm and they're like, wow, actually not only is

the type system more lightweight and easier to do things like structural typing and that

It feels like I'm fighting against things less to get the right types, but also it helps

me more when my types are actually incorrect.

Not just like I didn't put the correct identifier name, but actually like I have a problem with

It helps me more and I can actually trust it when it says the types are right because

I don't have array index out of bounds issues and I don't have unexpected exceptions and

things like that.

So anyway, I think that's like some important history that like a lot of these decisions

are learning from some of the lessons of like earlier versions of Java, which as you said,

like Java itself is learning from some of these things too.

So that's my rant about that.

But so you wanted to talk about any types.

So in JavaScript, nothing is typed.

So the thing that comes closest to that is the any type where the types basically has

no information about what the type can be.

And it uses that for things where it does not have any type definitions.

So something like packages from NPM, sometimes it doesn't have any information.

So it says everything's any arguments or any return types or any, everything's any.

And that is something that is contagious.

So if you have something that is that is any somewhere and then you do stuff on it, well,

that also becomes any.

I'm not entirely sure about how contagious it is and how that contagion works, but that's

how it feels at least.

Well, I mean, it's, I think it's pretty much exactly the same as if you used debug.to do

You know, the obvious difference being one debug.to do will never actually run.

It'll just halt the program.

And two, you can't compile it with the optimize flag in Elm.

In production mode.

But otherwise, I think it's the same.

There may be some slight differences, but effectively like the any type.

I mean, in Elm, it's the same thing where it just says this could literally be anything.

Like, oh, you mean anything like it could be a function that you could call.

It could be a function that takes this thing and turns it into this.

It could be a string.

Yeah, it could be anything.

So you could like call it as a function.

You could pipe it to something.

You could, it could be an opaque type.

It could be, it could be never, it could be anything, even if that's not even possible,

but the Elm type system will just say, okay, well, I guess this could be any value.

So it fits anywhere.

And then it will only complain if it tries to infer something based on it and finds out,

oh, okay, well this now needs to be a string because you use it where it's, where you need

And then it finds that some other place where the value also needs to be an integer or something.

And those are two contradictory values.

So you use an any type in two places that are contradictory and the Elm type system

will say, wait a minute, like, okay, I know, I know this could be anything, but it can't

be any two things at once.

And therefore something's wrong here.

So that is for Elm where, yeah, we do have any, but only for development mode, just to

help us work on something before it gets sent to production.

But what about TypeScript?

So how does it handle those conflicts of inference?

Let me do a quick example here in the playground and see what happens.

I'm curious too now.

From what I can see in my playground, it doesn't seem to be doing that kind of inference.

I'm seeing the same thing.

So I did an example where I said, let a be any type.

And then I defined a function that takes a Boolean and a number.

And I called that function with a and a.

And it says, yeah, that's fine.

So I think any does behave differently.

Well, I'll try to find some like posts on exactly how that type resolution for any works

and try to link to it.

But yeah, it appears that any is more permissive than an unbound type variable in Elm that

you can get with debug.to do that just says this could be anything.

So they're not exactly equivalent, it looks like.

That's very interesting.

Or rather the compiler does not do the same kind of checks.

Maybe at the moment, because every time I hear about a new TypeScript version, it seems

to do more and more checks, more powerful checks.

So maybe at some point.

Yeah, very interesting.

Okay, so a couple things to mention on the topic of any.

One is there's a type called unknown in TypeScript.

And unknown is very different from any.

In some ways, it's similar.

In some ways, it's different.

Unknown is saying you're going to have to prove what this type is before you can use

So for example, so I think one of the most important things to know as a TypeScript developer,

like someone who's writing TypeScript code, is that any is not just, you know, wherever

you explicitly use any.

Any happens all over the place, most prominently and most commonly in JSON.parse.

When you do JSON.parse, it returns a type any.

In fact, that's not even that's not even accurate, because JSON.parse will never return a function.

But a function exists in that set of types any.

So that's not good.

So it's not even being specific about it could be any JSON type string, bool, number, array

of those things, object of those things.

It's just yeah, it could be anything it could be a could be a function.

So when you do JSON.parse, be aware that that introduces a type and unsound type, as you

said, that is contagious throughout your application.

So so you know, there are tools like IO dash TS, and other similar tools that help do a

pattern similar to the JSON decoding pattern in Elm.

But so unknown is a really useful type to be aware of.

But But it's very important to realize that many of the published like typings for for

core JavaScript functions like JSON.parse return in any type.

It's very common for NPM typings that are published.

So a lot of NPM libraries will either come with TypeScript types when you install them

with NPM install, or they will have a separate set of typings that you can install separately

with this definitely typed package, I'll link to this thing where you can search for packages

that have this definitely typed thing.

But it's very common for those to use any as well.

And as far as I know, there's not really a way to warn you if you're pulling in an any.

Yeah, I mean, there's no implicit any, but it doesn't help with that, right?

So no implicit any is like an option you can set in your TS config.json.

And you should definitely use the strictest possible settings for that, including strict

mode, but but you should be more strict than that I write about that a little bit in a

blog post that I'll share called TypeScript spline spots.

But yeah, so no, no implicit any will prevent you from saying like function greet takes

a name and then doing something with it.

And it'll say, Hey, since you didn't put a type annotation on the parameter name, I'm

implicitly assuming that that's an any type.

So the TypeScript is saying if you would like to use an any type there, which I just inferred

that to be because you didn't explicitly give a type to the parameter because sure, you

treat it like a string, but you can treat a lot of things like a string you can in in

JavaScript, you can concatenate an object and a string and that's fine.

As far as JavaScript semantics go, you can use a you can use a number or an object in

a conditional check if object if number and those semantics are proper JavaScript semantics,

they're they're confusing and they're often foot guns.

And that's one of the like, so this is an important thing to note is that the soundness

of Elm, it's more than just soundness, it's also like explicit semantics where Elm will

say, Hey, if you want, if you want a Boolean check, I know you might be passing like some

maybe value and saying if maybe value, but that's not how you do that in Elm.

If you'd like to say if it if it is not nothing, then you need to do that explicitly, you probably

actually want to do a case statement.

But if you really want to do that, explicitly turn it into a bool for me, because that's

probably a foot gun that so Elm will prevent you from unintentionally passing different

And that's something that makes it safer.

Strictly speaking, in terms of soundness, it doesn't really affect the soundness of

the type system.

But practically, it does.

Wait, let's get back to the grid function that you mentioned.

If you do not put any type annotations on the arguments, they are all considered any

exactly, exactly.

Because, well, maybe not regardless of the implementation, but but if you're concatenating

two things, then it can't infer the type based on that.

So sure, you're concatenating two things, but I can concatenate a number with with a

string in JavaScript, JavaScript lets you do that.

So sure, you're saying hello plus name, but I can't infer that that must be a string based

Whereas Elm can, Elm can infer that and it's not going to say, Oh, I don't know what type

this is, it's going to say, Oh, that must be a string because you're doing string plus

plus something that thing must be a string.

TypeScript can't do that.

So if you say no implicit any in your type script configuration, then it will try to

say it's unknown or it will let you know, hey, please add a type annotation.

Yeah, it will give you an error or a warning if you I think an error if you have no implicit

any and it will say, hey, I'm inferring this, this type, the name parameter to be of type

any, if you would indeed like it to be type any, then you must explicitly write that and

you can write that you can say, name, colon, any, and it'll say, Okay, fine, that's an

explicit any, I was giving you errors for implicit any.

And now you've made that explicit, and that's fine.

And so, of course, you could also explicitly put a different type like string in is the

type annotation for the parameter.

So that's that's no implicit any, but that doesn't prevent you from doing JSON dot parse

And suddenly, what value to get?

Do you get back any and now you, you know, as far as I'm aware, there's, there's no TypeScript

rule, not even like an ES lint type rule for preventing that if I'm mistaken, if there

is something then please, please let me know, because I'd love to learn about that.

But as far as I know, you can't, you can't prevent that or have some something that makes

you like, market explicitly, I think that would be really nice to, you know, to get

a warning if you do JSON dot parse, to at least have to explicitly write any if you

did, to acknowledge, I know I'm getting an any back here.

I'm guessing it would be useful, but I'm also guessing that it would be kind of annoying.

But I'm sure it depends on how likely are you to fight with your compiler to get things

So, so if you are doing something pretty complex, and you don't know how to type it, because

JavaScript is very complex and you can do very complex things with it, then potentially

like the only thing that you can do is to say it's any.

Or to go through the whole documentation to find exactly how to type it.

And that can be very complex.

I think you're spot on.

And I think another, another thing is like, what if you do JSON dot parse and pass that

down to something else and that passes something else and returns type and then through that

chain of function invocations, you end up with something that's not any.

Well, is it going to tell you anytime you use something that returns an any and force

you to assign it to a variable somewhere or how would that even work?

I mean, that wouldn't be practical.

So, so I think that the, you know, TypeScript language is just like, Hey, that's, that's

just part of it.

Like you get any somewhere.

And really I think, I think the philosophy is it's really more like a, a, a linter where

it it's a bonus that it catches some things and it does its best effort.

And again, I don't, I don't mean this as a value judgment.

I just, I just, I think that when you're writing TypeScript, which I, I use TypeScript and

I think it's, I think it's great, but I think you need to be aware of these things when

you use them, not just think like, Oh, it's typed.

No, it's, it's typed in a very different way.

And it's pragmatic for the goals it's solving for.

But so that's, that's why I wrote that post TypeScript Spine Plots.

And it's, it's one of my, one of my favorite posts that I've written.

It's a short little one, but my, my goal with that post was for myself as much as for anybody

to document these these cases to be aware of that could end up shooting you in the foot.

I guess what you're saying is it really depends on how you view it.

Like sure you can, if you're just trying to write JavaScript and then add type annotations

to catch some errors, then yeah, it's a lender in a way.

A very powerful one at that, but it has its limitations.

But if you're thinking that you're not developing JavaScript, but you're writing TypeScript,

then I think you're going to write your code differently.

You're going to write it probably in simpler ways in ways that you can, that you know how

to type them and you will do less dynamic things.

You will do less dynamic constructs and you will be more explicit in everything that you

do, which I think is the way to go.

But that's from a biased opinion as well.

Yeah, no, I mean, that's why I wrote this blog post for myself when I'm writing TypeScript

code because I wanted to, to just like have a quick reference of what are the things that

introduce unsoundness, not because I'm never going to use them, but because I, in my mind,

I want, I want a bright red ring in my brain around it whenever I see JSON.parse.

And you know, so for me writing this blog post succeeded in doing that in my brain where

I, you know, anytime I see JSON.parse, I'm like, uh oh, there's a, there's an any that's

trickling through my types now.

Same as when you call HTTP requests, right?

Yeah, yeah, cause you, I mean, cause it's JSON.parse under the hood.

JSON.parse is just used so many places and same when you install in a typings of an NPM

package and you know, so yeah, you have to, you have to be very skeptical of typings that

come from the outside.

You have to be a little bit paranoid.

So we mentioned that unknown is a better alternative to any when possible at least, which I think

it's most cases, but when you use unknown, what you need to do is to narrow the type.

You need to tell TypeScript how do you, how can I tell you that this will be a string

or that this will be something else?

And what you do for that is to say things like if a value contains, has a property to

uppercase or, or you call things like array.isArray or use type of stuff like that.

Usually you'd want to do type of rather than checking for a property on string.

But yeah, yeah, yeah.

You can just say type of, and it, and this is one of the really interesting things about

TypeScript is it, it uses control flow analysis in order to narrow types as you, as you're

And I noticed that in Elm, you don't have any of those.

The only thing that you have is better matching.

You can have validation functions, but then how do you use those values?

You use better matching or things like maybe that with default or result that with default,

but then you lose some information.

And under the hood it's pattern matching anyway.

Because they're coming edit.

And again, you know, I mean, I guess I, I guess I sound like a broken record here, but

I always, I always like to think, you know, what are, what are the design constraints

and the problems that the author is trying to solve for, right?

And in the case of the TypeScript compiler, like what, what problem are they trying to

And if you get in the shoes of the compiler authors, the problem they're trying to solve

is well, we have an untyped language, JavaScript, and what we have, what does code do now?

Cause we want to fit into that.

Well, what people say, if value is no, else if type of string else if type of whatever,

and you know, you can do that to, to check the types.

Well, okay, well we can do some, some control flow analysis to, to narrow the types in those

cases based on runtime checks.

Whereas Elm is a language built from the ground up to be a type safe and type checked.

And so Elm says, actually I have these constructs specifically for narrowing types.

And actually in, in Elm, a very important distinction between Elm and TypeScript is

that Elm does not have untagged union types.

It only has tagged union types, which means, whereas in TypeScript you could say if type

of value equals, equals, equals string, then do something else.

If type of value equals, equals, equals object in Elm, there's no such thing because if it's

a string, it's a string.

If it's a maybe string, then okay.

Case of these two variants, but it's actually not a maybe string.

It's a, it's a maybe with one of two variants, but it's not like a string or an object or

a it's only one type of thing.

You can't say it's a string or a number.

There's no such thing.

Which I think is actually a very cool feature of TypeScript that you can have a true union

in the sort of like mathematical set theory sense of the term where you could have a function

argument that accepts, you know, it accepts strings.

And then you say, actually, if you, if you pass null to it, it has a specific meaning.

And then you can keep all of the previous code compiling, but also accept a new type

that didn't compile before because it's a proper union.

Whereas in Elm, if you, if you were to change that suddenly all the code that was passing

in strings, now it has to be just string.

So everything has to put a tag in front of it now.

So I think that's like a pretty cool feature, but, but that's that's definitely one thing

to, to, you know, really try to understand is, is how much TypeScript is fitting into

runtime checks that you could do in JavaScript.

And actually it does do in JavaScript.

And then it's using control flow analysis to narrow the types within that, which is

very pragmatic and really, really neat.

I don't know if I like the string or null in practice.

But I do think I do like the string or number or string or username, which I think is, I

think it's pretty neat.

As long as it compiles as a proper checks afterwards, which I imagine it does.

Well, be sure that you have strict null checks on that's another tsconfig.json option, which

I highly recommend just using strict mode.

Do you want to talk about nulls and then undefined in TypeScript?

Null and undefined.

Is it that bad?

Well, it always just throws me off how there are these two different ways to represent

this thing, but yeah, I don't know.

I don't know if I have that much to say about it other than why, why do we have two different

ways to represent absence of values?

My, what I always find interesting with JavaScript, not TypeScript, JavaScript is that zero divided

by zero is not a number.

It's an N. But if you look at what the mathematicians say, they say it's undefined.

Even in JavaScript, like the only language that has undefined, but even there it isn't

If you're a mathematician and you go to write some JavaScript code, let's just say you're

probably going to be pretty confused.

You'll be like using an equals operator to like change the values of things.

And you're like, hmm, I don't think that's what equals means.

And then it's like, oh, are you, are you thinking of triple equals?

It's like, what is triple equals?

Are there no double equals?

Oh, we don't use that.

Yeah, no, that's rubbish.

Until how many equal signs does it go?

We use linting checks to disable double equals.

It's a bug if you use double equals.

Do you say something like equal with an exponent?

Like equals to the power of three to say triple equals?

Or three equal?

What I'm wondering about, and maybe this is just a simple lookup documentation type of

question, but if you say something like string or null, does a null mean it's the null value?

Or it is null or undefined?

That I find pretty weird because a lot of things, and I see null everywhere in TypeScript,

but I also know that undefined is used everywhere because you're missing arguments or stuff

Missing arguments, you look something up in an object and it doesn't contain the key.

But then you get undefined, you don't get null.

So does TypeScript tell you about those?

Like, oh, this is probably null.

That's a good question.

I mean, for all intents and purposes, they're going to be similar because a lot of the time

you're going to say, I mean, if you do, a lot of the time you're going to say if value

then, and so it doesn't matter because it's checking truthiness, not strict equality.

Poor number zero.

Poor empty string.

It makes me so happy writing Elm and not having to think about which ones evaluate to false

and which ones evaluate to true.

I will never trust myself with those things.

I'll never trust myself with those things and I will never trust myself with precedents

of or and end and things like that.

Like in Elm, I always write it with parentheses and then let Elm format say, you don't need

The precedence rules will take care of that.

I'm like, okay, but at least I saw you do that and I knew what the precedence was before

I do the same thing.

So TypeScript also has the void type.

We don't because that is absolutely useless.

So void means, hey, I'm going to do a side effects.

There are no side effects in Elm.

I think void is short for avoid.

I'm fine with it.

I needed one pun in the show.

What I find interesting, but also entirely normal because of the soundness argument that

we talked about before, is that there are no types for exceptions and there are no types

for experimentations.

So there's a lot of things that you do in TypeScript that do not reflect reality.

I feel like exceptions could have been documented, could have been annotated, at least somehow

to say, hey, I can guarantee you that this will give you an exception and this will be

I think that would be really cool too.

I think it's probably just a pragmatic choice that there are so many places where exceptions

throw the same type of error or exceptions throw a string or the place that throws an

exception is coming from a library that doesn't have typings.

But Java has this notion of handled or checked exceptions and then there's also runtime exceptions.

So it's kind of weird because you get this specific set of types of exceptions that can

be thrown and exceptions that are handled.

That's cool, but then you throw something that's a subtype of runtime exception and

it doesn't have to tell you about that.

Because the idea I guess is like, well, these are things that are unexpected and unrecoverable

or something like that.

So it wanted to have an escape patch to be able to say, hey, if I'm trying to read a

file and the hard drive isn't working, I don't want to make every user handle that state.

But I don't know.

I mean, yeah, I think it's really nice that Elm lets you be so explicit that they're just

And if you don't want to handle something, then you at least have to be explicit in doing

a catchall or whatever you want to do to pass that through.

But yeah, I mean, TypeScript made the choice to not have a notion of sort of checked exceptions.

And I agree, I think it would be cool.

It would be a nice feature, but I'm not sure if there are any plans for something like

But so that is another blind spot of the TypeScript type system.

Is it in your blog post?

You did a good job, Dillon.

It's my catalog of places you can introduce unsoundness.

If you find something that's not in there, please let me know because I'll try to keep

it up to date with any other things people think of.

So okay, so before we finish, I think it would be nice to maybe we can go through this catalog.

But one more thing I wanted to touch on is like this difference in the Elm and TypeScript

type systems of custom types with variants in Elm.

Yeah, we should talk about those.

And discriminated unions in TypeScript.

So discriminated unions are very cool.

And I think it's important to realize that as far as just the feature of a discriminated

union goes, it's a pretty sound feature.

Can you explain what those are?

Yeah, absolutely.

So now again, if you want to understand the TypeScript type system, think about the the

motivation and design constraints of the author.

So similar to type of string checks, it uses narrowing using kind of code flow analysis.

Same with discriminated union.

Dillon, you sound like a broken object.

That's a good one you're in.

And that might have to go on a t shirt.

Sounds good to me.

But yeah, so it's using the same technique of this sort of runtime analysis check that

it hooks into to narrow the types to give you type information in that context of the

And so if you have a field in an object, which can be, you know, a shape has a, you know,

you have an object, which can can either be shape is square, and then it has a width field

Or, so this would be like a union type using the pipe operator.

So you could say like type, shape equals, and then an object, shape, colon, square,

the string square.

So it's that's actually a string that type is a string.

And then and then you can have width is a number.

And then you could have or pipe, it's a an object shape, colon, string rectangle, and

it has the property with number, height number.

So now, what TypeScript is going to do is if you have a value of that type, you can

do like a switch statement, or an if statement or whatever, right?

Because it's just you're just doing a runtime check like you would if you actually had those

So you would say, you know, if shape dot, well, shape dot shape equals square, then

you know that it must have based on the type definition, you know that it has a width and

it doesn't have a height.

And if it's a rectangle, you know, it has a width and a height.

And if it's a circle, you know, it has a radius or whatever it may be, right?

So this is how unions work.

TypeScript has this notion of like literal values, which is a really cool feature.

So like a literal value, you could have a type string, but you could have a, you know,

You could have a sub.

So you could have like a mode argument to something, you could have a parameter that's

And mode is a string and well, what do you pass it?

You say mode is either verbose or silent or something like that, right?

And well, if you know the specific subset of strings that it could be, then you would

just say mode is either verbose or silent and you could add different things to it.

But that's the literal string.

It's not a, you know, magical variant type like in Elmore, it's the specific thing.

It's just a string, but you're saying this can only be these strings.

And again, using this sort of control flow analysis, TypeScript can say, Hey, you're

passing a literal string and you're passing the string, you know, loud instead of verbose.

And it'll say, Hey, you can only pass verbose or silent here.

So this string is incorrect.

So it it's actually analyzing the values of your code.

Whereas in Elm, you would have to define a custom type, which you could not reuse.

It would be only for those places.

It's like a nominal type.

It's a nominal tape and that works well, but it's also sometimes quite annoying.

And so I do like that part about TypeScript.

It's very pragmatic.

It's a very, very nice feature.

And you know, and if you, well, I'm not sure it's pragmatic.

I think it's just a good feature.

I mean, they didn't have to be.

I mean, in a way I think they did because TypeScript, you know, in a way TypeScript

is almost like descriptive rather than prescriptive.

It's like TypeScript is a type system to, to attempt to describe how people use JavaScript,

not how people should write code.

And that's what people, people do.

They pass literal strings and then they check if the string is, you know, verbose or if

the string is silent, then I'm going to change the behavior.

And people can still pass in anything else in JavaScript.

So I find that the fact that they can specify a subset is just an additional feature that

they met, that they made.

And that is awesome.

They don't do the same thing for numbers as far as I'm aware.

You can't say, oh, this number is one or two.

Or I guess maybe you can with EGEM.

Actually, I think you can.

Is that what you've done so far?

I think you can do that.

And well, that's awesome.

I wonder how they do that with like concatenations and additions, subtractions, how they can

tell whether something is indeed within the limited ranges or limited sets of values.

Well it's weird with Java.

So I just tried doing a literal type to say like, you know, type version equals one or

two and you can do that.

You can absolutely do that.

And then if you say, you know, let version of type version equal one or equal two, it's

And if you say it equals three, it says that's not of type version.

The strange thing is you can do that with like floats, which float equality should not

So anyway, that's a little bit odd and probably something you should be skeptical of.

But doing it with integers, which yes, they're all just numbers, but if you only use integers,

then that's safe.

But yeah, and I think enums under the hood are just using integers.

And I think you can assign them other values than just the order.

So yeah, you actually can, I think.

That's pretty cool.

Yeah, it's a very cool feature.

So discriminated unions are just taking advantage of that notion of literals, but they're saying,

well, this object has a key, this discriminant, this key that can tell me what the shape is,

because if this key shape is square, then I know what fields and of what types it has.

If it's circle, then I know what fields and what types it has.

So it's just using that same technique of sort of type narrowing using conditional flow

And it's just leveraging that along with like this notion of literal types where you can

say shape square, the string square.

And you just and all you have to do is if you if you check if, you know, shape dot shape,

triple equals square string square.

Now you've narrowed down that type because it has enough information to infer some things

about the type based on that.

So that's how discriminated types work.

And it's a very cool feature.

So the one thing that's very, very different in this regard between element and TypeScript

is like, if you're just using a plain old discriminated type, it works quite well, you

know, it's, it works pretty much like you would expect as an Elm developer.

But then when you when you want to create an opaque type, that's when things get very

I don't want to I don't want to say anything that's that's no longer accurate, because

I know that there are some changes, like with regard to like private methods, and that sort

of thing lately.

So and I'm not familiar with the latest in that.

So things may change in this regard.

I also know there's like a feature called branded types.

And to be honest, I've tried to try to use just use them and I don't understand them.

I haven't been able to figure it out.

So if you figure it out, try it and like, let me know how it works.

Yeah, it works.

From what I understand, like a branded type allows you to, to do something similar to

an opaque type in Elm.

But all I can all I can say really is that in my personal experience, branded, I've never

seen a branded type in actual use.

I'm sure there are some libraries that that use it.

But it like, practically, I don't think people people use branded types on a day to day basis.

Whereas in Elm, people use opaque types.

So that's, that's all I feel I can safely say I think a feature may exist to get the

same type of functionality as an opaque type.

In practice, I don't think it's very common.

That's something that I think is huge.

I can't overstate the importance of opaque types as far as like, because soundness is

one thing, but protecting invariants is actually a separate thing.

It's actually not related to soundness.

And like protecting invariants is more about controlling the internals of an API.

So you know, the only thing that can refer to this is in this one file, I can't touch

it outside of there.

And this is huge in Elm.

And if you're not, you know, if you're not doing this on a regular basis, check out our

episode on opaque types.

We talk about all the details of that.

I think it's a really important technique in Elm.

I think it's underused or overly difficult in TypeScript.

On a different topic, I should say one last thing about discriminated unions.

By default, switch statements in TypeScript are not exhaustive and they will not give

you a warrant, an error of any kind.

If you have a non exhaustive case statement, switch statement, there are, there's an ESLint

rule that I'll link to in the show notes for how to prevent inexhaustive switch statements.

So you should definitely do that to make TypeScript more safe.

I think that's really crucial.

There is like a trick you can use.

There's a never type in TypeScript, which is pretty much the same as with Elm.

And you can assert that something is unreachable by returning a never type.

So you can do default and then return something that returns never type.

And it'll say, wait a minute, you can't return a never type.

But if you can never reach there, then it won't complain.

If you do an exhaustive case and then you say default, return this unreachable never

type, then it'll say, well, okay, the default is never going to happen because you handled

But that only works as well as you remember to do that.

And I wouldn't trust that myself.

I would want it to have a blanket error anytime I do an inexhaustive switch statement.

So there are a few things that I find interesting.

I haven't played with those in TypeScript.

But you can kind of do dynamic typing in a sense like these types will depend on other

Perhaps dependent typing, if you will.

Don't confuse people.

Don't confuse people.

It's not dependent types.

I thought people could depend on you.

Ever since you started being an independent worker.

So yeah, you have something in TypeScript type system that are like you have key ofs

and type of where you can say, oh, this type here, that's just going to be any key of this

And then TypeScript figures out things on its own.

I haven't played with those and I don't know if it's if they're interesting or if they're

foot guns, just like how because they become dependent on what other code is doing.

And I feel like we're coming back to the argument about let variables and no type annotations

over there where if something changes, I kind of want to know.

So is it kind of like laziness or is it really interesting?

I mean, I think it I can't speak to the foot guns of it too much because I haven't encountered

There may be, but it certainly is a complexity in the type system.

And we've talked about this before, how like, I mean, I'll give my rant again briefly.

The reason we can trust types as like a proof about our programs is because of their simplicity.

Like the program itself is a proof to you could follow the flow and prove what it can

and can't do it.

But types give us a very simple proof that we can follow easily.

So the utility of a type is that we can, you know, our brains are able to track what the

types are because it's simple and the type system can help us enforce those simple constraints.

And we can reason about our code better that way.

So the simplicity of type systems can be one of the core features of it.

And this certainly adds complexity to the type system, which could make it harder to

follow the correctness of your program potentially.

But I know that like you can do some really interesting like metaprogramming type things

as library author using these types of features.

So there's like, there are some utility types and there are some really powerful like features

in the type system.

And I know that like the, you know, the Prisma team, for example, that have this like ORM

sort of like, you know, database invocation tool that uses TypeScript to make type safe

database queries.

They make heavy use of these advanced TypeScript features.

You know, if you like Google, Prisma, advanced TypeScript, you'll probably find some of their

like meetup talks and stuff.

I've watched some of them and they're very hard to follow.

My TypeScript foo is not advanced enough to follow the techniques they're using, but there

are some really advanced things you could do to build tools like Prisma where you can

describe the set of database queries you can make with a particular schema, which is very

Another interesting thing in TypeScript is like there's no tuple type in TypeScript.

There's just arrays.

They're technically, what I mean to say is the tuple type is not distinct from an array.

It's more of like a literal type.

It's like a literal of an array with two entries.

There's a tuple type, but there's no tuple value.

It's not a distinct special type.

It's more like a literal, just like a discriminated union.

It's not really a type.

It's like a literal and it uses these sort of type narrowing techniques with the conditional

control flow to check that.

So, yeah, you can say this is an array, but specifically it's a subset of arrays.

It's not just any array.

It's the subset of arrays that contain two values of this type, which I think is very

Whereas in Elm, a tuple is more like a nominal type.

It's kind of an in between sort of thing because it actually is like a special thing, but I

think that's a cool feature of TypeScript.

And there's no upper size limits for tuples in TypeScript.

For better and for worse.

Can you give me a short summary on the differences between interface and type and declare, I

It is short too much to ask.

Type aliases versus interfaces.

There's like a lot of debate around which is better, which is like faster for compiler

performance, which has whatever.

I think I've heard people have this discussion and I don't think there's like a clear answer.

At least there's not a concise way to describe it.

I tend to just use type aliases because it feels more natural as an Elm developer to

use a type alias to like an object type definition.

So that would be the type keyword, right?

And then interface.

Because, yeah, because it's like...

Is interface about objects?

Yeah, interface is like saying that it's an object with a subset of particular keys.

And then there's like strange stuff where many different types of things are actually

objects under the hood.

So you can extend the array type in TypeScript and there's all sorts of...

So personally, I just like not to think about those details and I just use type, the type

But that's just me.

And that's because you don't want to use JavaScript, you want to use a typed language.

You don't see TypeScript as a linter, you see TypeScript as a language with types that you

can use and understand.

And I also prefer to pretend that inheritance doesn't exist because it's very confusing

in general and particularly confusing with prototypal inheritance in JavaScript.

Well, I think we've covered things fairly thoroughly.

In a very systematic and organized fashion.

Now definitely check out this TypeScript blind spots blog post.

I have like a few other cases to be aware of.

And again, please, truly, if there's anything else that you are aware of that introduces

unsoundness into the TypeScript type system, let me know and I will catalog it there because

I think that's just a good thing to know, where you can trust it and where you can't.

But check that out.

I've also mentioned my TypeScript without transpilation post before that kind of talks

about using js.comments to get type information.

I think that's a useful technique.

So we'll link to that blog post.

Any other good resources?

And what if I want to use Elm with TypeScript?

Oh, well, I'm glad you asked.

Elm TS Interop.

I'm actually just releasing a new version of the community edition and a new doc site

So by the time you hear this, it'll already be out.

As well as a new pipeline API and codec API for the Elm TS JSON API.

So yeah, check that out.

Check out our Elm TS Interop episode.

What other resources are there?

The TypeScript documentation site has a lot of good examples.

Do you know of any TypeScript to Elm comparison files or something?

That's a good question.

There are a bunch of search results, but a lot of them are these generic stack ups type

sites that I don't find that useful because they're sort of mechanical.

But if we find a good one, we'll link to it.

Well, until next time.

Until next time.