7 ms·

Eventually, node might allow JS to introspect those types. That would be a huge win. Right now in Python, great tools like pydantic exist because Python can in

Eventually, node might allow JS to introspect those types. That would be a huge win. Right now in Python, great tools like pydantic exist because Python can introspect said types, and generate checks out of them. This mean you can define simple types, and get: - type checking - run time data check - api generation - api document generation Out of a single, standard notation. Right now in JS, things like zod have to do: const mySchema = z.string(); Which is basically reinventing what typescript is already doing.

aitchnyu 2y ago
Does this mean Node can know if an exception is subclass of ValueError or an object is instance of SomeClass? I'm a TS newb, I thought types outside of array, object, number, string arent present in JS and Zod and typeguard functions return plain objects with "trust me bro".
- LelouBil 2y ago
  You are right, they aren't. In the JavaScript languages which is what gets actually executed, there are no typescript types. The parent commenter was talking about a way for nodejs to provide, via an API, the content of type annotations on fields/functions/variables like in python. However, in python the type annotations are a property of the object at run time, whereas they are completely stripped before execution for typescript. So I'm not sure how it would work except by changing the typescript philosophy of "not changing runtime execution"
- gampleman 2y ago
  In JS, classes do retain runtime information. So the `instanceof` is a real runtime operator that works by checking the prototype chain of an object. So checking subclasses can be done at runtime. However, in TS other type information is erased at compile time. So if you write type Foo = "a" | "b"; the runtime code will see that just as a plain string.
bythreads 2y ago
That's not entirely true. `z.string()` in Zod offers more than just type safety akin to TypeScript. TypeScript provides compile-time type checking, while Zod adds runtime validation and parsing. For those unfamiliar: `z.string()` effectively converts `mySchema` into a functional schema capable of parsing and validation. For example: `mySchema.parse("some data")` returns successfully. `mySchema.parse(321)` throws an exception. I've used it in places where you need runtime validation and in process verification - it works pretty well for that and you can extract the types from it via : const A = z.string(); type A = z.infer<typeof A>; // string Meaning if you define your types in zod first, and infer their types from that you get compile and runtime type checking. --- It a bit of an overkill for nimble and fast code bases though - but works wonders for situations where in process proofing needs to be done, and in all honesty it isn't that big of a task to do this.
- Dylan16807 2y ago
  > Zod offers more than just type safety akin to TypeScript. TypeScript provides compile-time type checking, while Zod adds runtime validation and parsing. Well of course it offers more, or you wouldn't be installing a library. The problem is that even when you're expressing normal Typescript types, you have to use entirely different syntax. It's good that you can usually avoid double-definition, but it's still a big barrier that shouldn't be necessary.
- tommy_axle 2y ago
  There's also typescript-to-zod that makes it possible to generate the zod schemas from your types.
MrBazlow 2y ago
A lot of the focus by the TypeScript team is focused on alignment with the JavaScript language these days and novel new features such as run time types have all but been dismissed or at the very least pushed behind the TC39 JavaScript types proposal. Much like using decorators on variables outside of class structures was. Having said that, TypeScript allows plugins, these are very rarely used as they augment the language by introducing other features that are transformed into the resulting JavaScript files. One plugin that relates to your suggestion of run time types is called Typia, it permits you to use your TypeScript type signatures at runtime with guards like `assert<MyType>(myValue)` where it intercepts the function call to construct an exhaustive if statement in the transpiled JavaScript checking the nature of the passed variable. So while I don't see it being a part of the language in the next four to six years, there are at least libraries out there already that allow you to do it today.
hajile 2y ago
If JS ever adds type checking, I hope it doesn't choose Typescript. We need a type system that is actually sound and TS is intentionally unsound. We need a type system that doesn't allow bad coding practices like TS does. We need a type system that enforces program design that allows programs to be fast. We need a Hindley Milner type system. If you want a module to be typed, add a `"use type"`. This should disallow bad parts of the language like type coercion. It should disallow things that hurt performance like changing object shape/value type or making arrays of random collections of stuff. Incoming data from untyped modules would either coerce or throw errors if coercion can't be done at which point the compiler can deeply-optimize the typed code because it would have far stronger type guarantees and wouldn't have a risk of bailing out.
- ahuth 2y ago
  What bad coding practices does TS allow, and why are they bad?
  - hajile 2y ago
    If there's a bad way to write JS, TS has something available to make sure it's typed. Does TS help you keep your functions monomorphic so they'll get optimized by the JIT? nope Does TS keep your object shape from changing so it will get optimized by the JIT? it actively does the opposite giving TONS of tools that allow you to add, remove, modify, and otherwise mess up your objects and guarantee your code will never optimize beyond the basic bytecode (making it one or two orders of magnitude more slow than it could otherwise be). TS doesn't do anything to prevent or even discourage these kinds of bad decisions. They "type soup" many projects fall into is another symptom of this. The big reason the types become such a mess is because the underlying design is a mess. Instead of telling programmers "fix your mess", TS just releases even more features so you can type the terrible code without fixing it.
    - tln 2y ago
      > Does TS keep your object shape from changing so it will get optimized by the JIT? it actively does the opposite giving TONS of tools that allow you to add, remove, modify, and otherwise mess up your objects and guarantee your code will never optimize beyond the basic bytecode (making it one or two orders of magnitude more slow than it could otherwise be). Can you elaborate or point to some of the tools? So I know what tools I may need to avoid

aitchnyu 2y ago

Does this mean Node can know if an exception is subclass of ValueError or an object is instance of SomeClass? I'm a TS newb, I thought types outside of array, object, number, string arent present in JS and Zod and typeguard functions return plain objects with "trust me bro".

LelouBil 2y ago
You are right, they aren't. In the JavaScript languages which is what gets actually executed, there are no typescript types. The parent commenter was talking about a way for nodejs to provide, via an API, the content of type annotations on fields/functions/variables like in python. However, in python the type annotations are a property of the object at run time, whereas they are completely stripped before execution for typescript. So I'm not sure how it would work except by changing the typescript philosophy of "not changing runtime execution"
gampleman 2y ago
In JS, classes do retain runtime information. So the `instanceof` is a real runtime operator that works by checking the prototype chain of an object. So checking subclasses can be done at runtime. However, in TS other type information is erased at compile time. So if you write type Foo = "a" | "b"; the runtime code will see that just as a plain string.

bythreads 2y ago

That's not entirely true. `z.string()` in Zod offers more than just type safety akin to TypeScript. TypeScript provides compile-time type checking, while Zod adds runtime validation and parsing. For those unfamiliar: `z.string()` effectively converts `mySchema` into a functional schema capable of parsing and validation. For example: `mySchema.parse("some data")` returns successfully. `mySchema.parse(321)` throws an exception. I've used it in places where you need runtime validation and in process verification - it works pretty well for that and you can extract the types from it via : const A = z.string(); type A = z.infer<typeof A>; // string Meaning if you define your types in zod first, and infer their types from that you get compile and runtime type checking. --- It a bit of an overkill for nimble and fast code bases though - but works wonders for situations where in process proofing needs to be done, and in all honesty it isn't that big of a task to do this.

Dylan16807 2y ago
> Zod offers more than just type safety akin to TypeScript. TypeScript provides compile-time type checking, while Zod adds runtime validation and parsing. Well of course it offers more, or you wouldn't be installing a library. The problem is that even when you're expressing normal Typescript types, you have to use entirely different syntax. It's good that you can usually avoid double-definition, but it's still a big barrier that shouldn't be necessary.
tommy_axle 2y ago
There's also typescript-to-zod that makes it possible to generate the zod schemas from your types.

MrBazlow 2y ago

A lot of the focus by the TypeScript team is focused on alignment with the JavaScript language these days and novel new features such as run time types have all but been dismissed or at the very least pushed behind the TC39 JavaScript types proposal. Much like using decorators on variables outside of class structures was. Having said that, TypeScript allows plugins, these are very rarely used as they augment the language by introducing other features that are transformed into the resulting JavaScript files. One plugin that relates to your suggestion of run time types is called Typia, it permits you to use your TypeScript type signatures at runtime with guards like `assert<MyType>(myValue)` where it intercepts the function call to construct an exhaustive if statement in the transpiled JavaScript checking the nature of the passed variable. So while I don't see it being a part of the language in the next four to six years, there are at least libraries out there already that allow you to do it today.

hajile 2y ago

If JS ever adds type checking, I hope it doesn't choose Typescript. We need a type system that is actually sound and TS is intentionally unsound. We need a type system that doesn't allow bad coding practices like TS does. We need a type system that enforces program design that allows programs to be fast. We need a Hindley Milner type system. If you want a module to be typed, add a `"use type"`. This should disallow bad parts of the language like type coercion. It should disallow things that hurt performance like changing object shape/value type or making arrays of random collections of stuff. Incoming data from untyped modules would either coerce or throw errors if coercion can't be done at which point the compiler can deeply-optimize the typed code because it would have far stronger type guarantees and wouldn't have a risk of bailing out.

ahuth 2y ago
What bad coding practices does TS allow, and why are they bad?
- hajile 2y ago
  If there's a bad way to write JS, TS has something available to make sure it's typed. Does TS help you keep your functions monomorphic so they'll get optimized by the JIT? nope Does TS keep your object shape from changing so it will get optimized by the JIT? it actively does the opposite giving TONS of tools that allow you to add, remove, modify, and otherwise mess up your objects and guarantee your code will never optimize beyond the basic bytecode (making it one or two orders of magnitude more slow than it could otherwise be). TS doesn't do anything to prevent or even discourage these kinds of bad decisions. They "type soup" many projects fall into is another symptom of this. The big reason the types become such a mess is because the underlying design is a mess. Instead of telling programmers "fix your mess", TS just releases even more features so you can type the terrible code without fixing it.
  - tln 2y ago
    > Does TS keep your object shape from changing so it will get optimized by the JIT? it actively does the opposite giving TONS of tools that allow you to add, remove, modify, and otherwise mess up your objects and guarantee your code will never optimize beyond the basic bytecode (making it one or two orders of magnitude more slow than it could otherwise be). Can you elaborate or point to some of the tools? So I know what tools I may need to avoid