Sure, but ten years ago, if I told you the concept of a "bottom type" would be common knowledge with web developers or they'd consider type algebra second nature, you'd have laughed at me. If I were to tell you they pushed a Turing complete type system into the mainstream and then abused its computational power to do things like create value types, you'd ask me where I was buying my LSD.

TS might not be the most robust type system in the world with no qualifiers. And it might not even try to be sound. And it might disappear at compile time. But none of that changes the fact that it took a bunch of concepts that only programming language dorks knew or cared about and turned them into every day utilities that the junior most developers use. And it doesn't change the fact that it is the only mainstream programming language with a fully Turing complete type system.

Give credit where it's due. I say all of this as one of the aforementioned programming language dorks who took a really long time to get on board with TS, as I thought Flow's focus on purity made it a better choice.

> Sure, but ten years ago, if I told you the concept of a “bottom type” would be common knowledge with web developers or they’d consider type algebra second nature, you’d have laughed at me.

If you told me that was the case today with web developers generally, I’d laugh at you even harder than I would have if you made that prediction ten years ago.

All the web developers I've worked with in the last four years understand the concept of a bottom type, even if they've never been introduced to the formal phrase, because `never` is the explicit bottom type in TS and appears all the time. You can't go very long consuming libraries written in TS before you run into it, at which point you become familiar with it.

Similarly, a function that accepts (explicitly) `A | B | (C & D)` and then dispatches to functions that accept `A | (C&D)` vs `B` is, you guessed it, type algebra and is a common pattern in hot paths through every TS codebase.

Just because the formal nomenclature is unknown does not mean the concepts are unfamiliar.

> All the web developers I've worked with in the last four years understand the concept of a bottom type.

It's the opposite in my experience. Most web developers I work with (a lot because of consulting), specially the average "React sprint runner" doesn't have a clue about anything slightly above basic types and just google/chatgpt whenever things break so they can move on to the next task in the sprint.

cryptic typescript errors don't help here either.

Meanwhile what I see is that everyone seems to think the {} type in Typescript means an empty object. Just because something has expressive power doesn't mean it's good.

OK, that's all well and good but I notice you still haven't told me where you're buying your LSD?

Not to mention:

      type Thing = string | boolean;

      const arr: string[] = [];

      function add(item: Thing, dst: Thing[]): void {
        dst.push(item);
      }

      add(false, arr);

Is valid typescript.

If you are used to structural typed systems though this actually "feels" expected. Don't get me wrong, I know where you are coming from. But the realisation comes from nominal systems, which are different beasts. As long as it actually evaluates to the expectations in the head of the developers using it, then that's okay.

However, regularly it's not the case -- especially with people moving from nominal systems.

TS can't really be practically nominal when it has to be constrained by its compile target. So I guess it ultimately boils down to an anomaly/criticism born from the legacy of how web standards came about.

Nominal type systems are pretty much better across the board IMO. Much safer and much less to keep in your head. Modern langs like Rust or F# have very complete and nice to use type systems.

But yeah unfortunately not sure if JS is an appropriate target for these type systems. Nim does it, but I'm not sure how safe it is.

One language that comes to mind is ReasonML. It doesn't have runtime checking. It's structural and compile time, but the guarantees are supposedly cast iron. https://reasonml-old.github.io/guide/language/type#design-de...

    type thing = 
      | String(string)
      | Bool(bool);

    let arr: list(thing) = [];

    let add = (item: thing, dst: list(thing)): list(thing) => {
      switch (item) {
      | String(s) => dst @ [String(s)] 
      | Bool(b) => dst @ [Bool(b)]    
      };
    };

    let newList = add(String("asd"), arr);

This doesn't work, since the dst array has to be one that can contain both string and bool in the first place.

To me this is expected? Thing is supposed to be one or the other. If I wanted a homogeneous array I would use a generic <T> for the add function, which makes more sense for a function that just pushes to an array anyway.

arr was defined to be an array of strings. How are you pushing a boolean there?

Because you've given the function no information on whether those two "things" are related. You're saying when it gets passed into that function it can be treated as either with type widening.

I understand it may be unwanted at first glance, but this is a contrived example for demo purposes. You wouldn't really make an "add to array" function like this so specifically. You would use generics, which would solve the exact issue that is posed.

    function add<T>(item: T, dst: T[]): void {
        dst.push(item);
      }

Now you can work with any array, and it will only add items with the right type.

If you really need it to be just <Thing>, you can do this

    function add<T extends Thing>(item: T, dst: T[]): void {
        dst.push(item);
    }

Now it knows that Item and DST are related but need to be Thing.

Runtime safety is slower than compile type safety. Runtime safety SHOULD be opt-in if there's a performance penalty!

For runtime safety, there are lots of frameworks that follow TS's standard, one of the best is called "zod" which allows runtime safety and complex types are inferred.

Is there a type-system that provides runtime safety? I thought type-erasure was common practice

Raku has a really weird but cool type system[1] that does both compile time and runtime checks.

Because some checks are expected to be runtime only, it lets you specify types like "Odd integers" by writing a `where` clause.

``` subset OddInteger of Int where !(* %% 2) ```

You can use multiple dispatch to separate dispatch from processing: ``` subset Fizz where * %% 3 subset Buzz where * %% 5 subset FizzBuzz where * %% 15

  multi sub fizzbuzz(FizzBuzz $) { 'FizzBuzz' }
  multi sub fizzbuzz(Buzz $) { 'Buzz' }
  multi sub fizzbuzz(Fizz $) { 'Fizz' }
  multi sub fizzbuzz(Int $number) { $number }
  (1 .. 100)».&fizzbuzz.say;

```

Or even use inline anonymous subsets when you declare your functions: ``` multi sub fizzbuzz(Int $ where * %% 15) { 'FizzBuzz' } multi sub fizzbuzz(Int $ where * %% 5) { 'Buzz' } multi sub fizzbuzz(Int $ where * %% 3) { 'Fizz' } multi sub fizzbuzz(Int $number ) { $number } (1 .. 100)».&fizzbuzz.say; ```

Raku's type system is one of its features that will show you new ways of thinking about code. I advocate playing with Raku specifically for mind expansion because it has so many interesting ideas built in.

[1] https://docs.raku.org/language/typesystem

Out of all the type systems which provide safety at both compile time and run time, which are your favourites?

They're building a product that revolves around React and Typescript and include an email specifically for receiving investors, so it's reasonable that they'd talk up both technologies.

Can you name a common language with runtime type safety?

Anyway, you can get this with Zod https://zod.dev/