5 ms·

> the most robust type-system in the world (Typescript) This is very high praise for something that only provides safety at compile time and not runtime.

oorza 2y ago
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.
- dragonwriter 2y ago
  > 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.
  - oorza 2y 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.
    - hu3 2y ago
      > 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.
    - yencabulator 2y ago
      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.
- bryanrasmussen 2y ago
  OK, that's all well and good but I notice you still haven't told me where you're buying your LSD?
EddieRingle 2y ago
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.
emoII 2y ago
Is there a type-system that provides runtime safety? I thought type-erasure was common practice
- daotoad 2y ago
  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 https://docs.raku.org/language/typesystem
phpnode 2y ago
Out of all the type systems which provide safety at both compile time and run time, which are your favourites?
seveibar 2y ago
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.
angra_mainyu 2y ago
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.
- adamscybot 2y ago
  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.
  - consteval 2y ago
    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.
    - adamscybot 2y ago
      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-decisions 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.
shepherdjerred 2y ago
Can you name a common language with runtime type safety? Anyway, you can get this with Zod https://zod.dev/ https://zod.dev/

oorza 2y ago

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.

dragonwriter 2y ago
> 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.
- oorza 2y 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.
  - hu3 2y ago
    > 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.
  - yencabulator 2y ago
    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.
bryanrasmussen 2y ago
OK, that's all well and good but I notice you still haven't told me where you're buying your LSD?

EddieRingle 2y ago

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.

emoII 2y ago

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

daotoad 2y ago
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 https://docs.raku.org/language/typesystem

phpnode 2y ago

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

seveibar 2y ago

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.

angra_mainyu 2y ago

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.

adamscybot 2y ago
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.
- consteval 2y ago
  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.
  - adamscybot 2y ago
    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-decisions 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.

shepherdjerred 2y ago

Can you name a common language with runtime type safety? Anyway, you can get this with Zod https://zod.dev/ https://zod.dev/