News for hackers. Stuff that matters.

A comment on TypeScript 5.0. Parent comment

Re:TypeScript 5.0 by throw_m239339 on Thursday March 16, 2023 @03:17PM (#35186904)
> I have a strange take - I think Typescript types are better most other languages, including Java, C++ and Go. It's strange since TypeScript is adding types to a weakly typed language.

Typescript types don't exist at run time, at all. So it's easy to be better when your language is merely about static analysis as it will not enforce any sort of type system during runtime. Java, Go or C++ have different constraints.

[ Parent | on HN ]
Re:TypeScript 5.0 by dimitropoulos on Thursday March 16, 2023 @03:32PM (#35187122)
that's a false equivocation in the sense that you just moved the goalposts by defining what "runtime" means.

There are no types whatsoever as far as processors are concerned. No types in assembly Not for Go or Java, not for C, and not for Rust. All you gotta do is keep compiling.

[ Parent | on HN ]
Re:TypeScript 5.0 by throw_m239339 on Thursday March 16, 2023 @03:35PM (#35187169)
> that's a false equivocation in the sense that you just moved the goalposts by defining what "runtime" means.

I disagree, Javascript does have types and runtime type errors, just not all the ones Typescript compiler has, it makes Typescript extremely leaky as a Javascript abstraction. Typescript compiler cannot represent every single Javascript type combination either, it will would have to be a Javascript interpreter at first place.

[ Parent | on HN ]
Re:TypeScript 5.0 by yencabulator on Thursday March 16, 2023 @05:43PM (#35189134)
Runtimes exist above processors, you know.

Here's types existing at runtime: https://go.dev/play/p/rc--yVzJ9bt

[ Parent | on HN ]
Re:TypeScript 5.0 by kaba0 on Thursday March 16, 2023 @07:16PM (#35190303)
To be honest, that’s the “default” way of type systems - without runtime reflection capabilities type erasure is just a normal phase of an AOT compiler, why would you store types?
[ Parent | on HN ]