3 ms·

> TypeScript compiles down to JavaScript, which doesn’t have types or type checking, it’s impossible to have actual type checking. The TypeScript compiler is gr

by barakm 9y ago

> TypeScript compiles down to JavaScript, which doesn’t have types or type checking, it’s impossible to have actual type checking. The TypeScript compiler is great at checking at compile time, but at the end of the day, it’s impossible to actually check the types. I'll point out that C/C++/Haskell compiles down to Assembly, which doesn't have types or type checking. GCC/LLVM/GHC is great at checking at compile time, but at the end of the day, it's all just bits being modified... Obviously you can find ways to break out of the type systems (void* cast?) but that's on you, and even if Typescript has more escape holes, the existence of them isn't an immediate fail

humanrebar 9y ago
> Obviously you can find ways to break out of the type systems... You can also accidentally have these issues if you are using incompatible pieces of software together. I was helping some colleagues with exactly this problem this week due to some changes in our toolchain. EDIT: I wasn't clear. This was in a C++ codebase, but the same issue would have happened in C or any other compiles-to-assembly language.
013a 9y ago
Good point. That being said, TS does suffer from something unique, in its JS interop. If my C program interfaces with a C library, I have great certainty that all of these were compiled at some point, and the types are sound (as much as C allows, at least). In TS, if you're lucky a library you consume was written in TS, so you've got high certainty that the typings it comes with are really good. Less lucky: the developer wrote it in JS, but provides typings. Less lucky: a random person on Github reverse-engineered the typings and provided them on DefinitelyTyped. Less lucky: There are no typings available. You'll run into npm libraries in all of these categories.
- barakm 9y ago
  Good to know; if this were a stated reservation, that'd be worth writing about.
- fny 9y ago
  Even less lucky: coding in vanilla JavaScript. In the days before Definitely Typed, I still got a lot of mileage out of types in my code alone. It felt immensely more apt then using JSDoc to document types everywhere. In my experience, even if you don't have types for a third-party library, you can get away with adding types for the interfaces you care about.
catnaroek 9y ago
> Obviously you can find ways to break out of the type systems (void* cast?) but that's on you Sometimes a type system can be proven to have no holes. (Of course, not counting the FFI, if any is provided.)
- barakm 9y ago
  Sometimes, but very rarely, if only because of FFI as you pointed out. And usually there's something in the unsafe category that lets you break some rules, if only to give a pressure release as in the interop reply above. I don't deny the existence of such a thing, just that there aren't many practical examples
savanaly 9y ago
Additionally, there's Elm which compiles to JS and its most memorable claim to fame is that it's a JS framework where "runtime errors are always a compiler bug".

by barakm 9y ago

humanrebar 9y ago

> Obviously you can find ways to break out of the type systems... You can also accidentally have these issues if you are using incompatible pieces of software together. I was helping some colleagues with exactly this problem this week due to some changes in our toolchain. EDIT: I wasn't clear. This was in a C++ codebase, but the same issue would have happened in C or any other compiles-to-assembly language.

013a 9y ago

Good point. That being said, TS does suffer from something unique, in its JS interop. If my C program interfaces with a C library, I have great certainty that all of these were compiled at some point, and the types are sound (as much as C allows, at least). In TS, if you're lucky a library you consume was written in TS, so you've got high certainty that the typings it comes with are really good. Less lucky: the developer wrote it in JS, but provides typings. Less lucky: a random person on Github reverse-engineered the typings and provided them on DefinitelyTyped. Less lucky: There are no typings available. You'll run into npm libraries in all of these categories.

barakm 9y ago
Good to know; if this were a stated reservation, that'd be worth writing about.
fny 9y ago
Even less lucky: coding in vanilla JavaScript. In the days before Definitely Typed, I still got a lot of mileage out of types in my code alone. It felt immensely more apt then using JSDoc to document types everywhere. In my experience, even if you don't have types for a third-party library, you can get away with adding types for the interfaces you care about.

catnaroek 9y ago

> Obviously you can find ways to break out of the type systems (void* cast?) but that's on you Sometimes a type system can be proven to have no holes. (Of course, not counting the FFI, if any is provided.)

barakm 9y ago
Sometimes, but very rarely, if only because of FFI as you pointed out. And usually there's something in the unsafe category that lets you break some rules, if only to give a pressure release as in the interop reply above. I don't deny the existence of such a thing, just that there aren't many practical examples

savanaly 9y ago

Additionally, there's Elm which compiles to JS and its most memorable claim to fame is that it's a JS framework where "runtime errors are always a compiler bug".