🎙 Elm Radio Episode 042: Comparing TypeScript and Elm's Type Systems

:studio_microphone: Elm Radio Episode 042: Comparing TypeScript and Elm’s Type Systems is out!

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

We hope you enjoy the episode!

6 Likes

I wrote a little post comparing Elm’s Opaque Types with TypeScript’s Branded Types. It elaborates a bit on the discussion from our Elm Radio episode today. Hopefully it clarifies how the Branded Type technique works in TypeScript as well.

4 Likes

Wouldn’t defining brand as readonly unique symbol enable you to hide constructor just like in Elm?

Yes, this is a great point @solificati! Someone brought that up on Slack today and we had an interesting discussion about the pros and cons there. I explored the idea a bit, but unfortunately I think there is still a similar problem when using unique symbols. If you export the type so that you can use it in type annotations, then you can still use that type to cast values outside of that scope.

I added a section describing that to the post. I love hearing things I might have missed, so do let me know if there’s anything else you think of! I would love to hear if there’s a nice solution that allows you to export types while ensuring those constraints that anyone is aware of.

1 Like

Hey, great episode keep it up :slight_smile:

Exploring TypeScript with Angular, I stumbled upon the “unsoundness” of it’s compiler while trying to use a library here:

In a nutshell, although one may feel fine about one’s code, external code can silently introduce gotchas (and I’d say pretty easily).

I think this may be a practical example of what you were expressing in this episode.

Side note: the library author did not fix this “bug”, and I didn’t feel it was worth exploring this avenue further

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.