Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reservations about TypeScript

daviesgeek.com

Post reply on HN
Print view View original

11–20 of 34 posts

Re: Reservations about TypeScript

#11

Post by nkohari »

daviesgeek wrote: post #7
Harkins wrote: post #6

First point: "I found a bug but can't give an example." Second point: "It adds a feature that's different from a similar language." These are not persuasive arguments. I'm not trying to be unkind, but the first point is totally unsupported and the second doesn't elaborate on what's bad about classes besides that another language also has classes.

Definitely agree on the first, that's a good point. I probably should've been better about how I presented the data. "TypeScript still compiles down to JavaScript. It has no way of actually checking types." That's my point. Maybe I should make it more obvious in the article :) I'm not complaining about the fact that TS has classes or types, it's that TS compiles down to a language that has neither.

That argument doesn't really make sense. The type system is a feature of the compiler, so why would the output of the compiler need to be aware of it? Lots of typed languages compile to machine language, which has no inherent type system.

Compilers which do add type information into the output are usually paired with a runtime that uses it for things like late binding or dynamic dispatch, but JavaScript doesn't support anything like that.

Could you give a concrete example of a scenario in which the flexibility of the JavaScript type system would break the TypeScript type system?

Re: Reservations about TypeScript

#12

Post by daviesgeek »

nkohari wrote: post #11
daviesgeek wrote: post #7

Earlier quoted context omitted.

Definitely agree on the first, that's a good point. I probably should've been better about how I presented the data. "TypeScript still compiles down to JavaScript. It has no way of actually checking types." That's my point. Maybe I should make it more obvious in the article :) I'm not complaining about the fact that TS has classes or types, it's that TS compiles down to a language that has neither.

That argument doesn't really make sense. The type system is a feature of the compiler, so why would the output of the compiler need to be aware of it? Lots of typed languages compile to machine language, which has no inherent type system. Compilers which do add type information into the output are usually paired with a runtime that uses it for things like late binding or dynamic dispatch, but JavaScript doesn't suppo…

All fair points and totally valid.

My concern is the facade/promise of type security.

Re: Reservations about TypeScript

#13

Post by humanrebar »

barakm wrote: post #8

> 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,…

> 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.

Re: Reservations about TypeScript

#14

Post by winstonewert »

daviesgeek wrote: post #4
kxkciicoiciic wrote: post #2

Article lacks any actual, factual reservations, but rather complains about some code that didn't work a year ago and the code of course has been lost. I don't get the point of sharing this writeup. I guess author just posted some text he wrote up for a internal company discussion. Opinions are like buttholes, everone has one.

I'd like to also point out that my main issue (that JS itself doesn't have types, so it's impossible for TS to 100% enforce it) still stands even after a year.

No, that point never made sense.

The fact that TS isn't sound has nothing to do with the fact it compiles to JS. If you wanted a sound type system, you should have checked out flow.

Re: Reservations about TypeScript

#15

Post by revelation »

daviesgeek wrote: post #7
Harkins wrote: post #6

First point: "I found a bug but can't give an example." Second point: "It adds a feature that's different from a similar language." These are not persuasive arguments. I'm not trying to be unkind, but the first point is totally unsupported and the second doesn't elaborate on what's bad about classes besides that another language also has classes.

Definitely agree on the first, that's a good point. I probably should've been better about how I presented the data. "TypeScript still compiles down to JavaScript. It has no way of actually checking types." That's my point. Maybe I should make it more obvious in the article :) I'm not complaining about the fact that TS has classes or types, it's that TS compiles down to a language that has neither.

Hello, at the end of the day it's all wildly swinging voltages imperfectly mapped to ones and zeroes. There are no types in any of this. It's all a huge number of abstractions stacked on top of each other.

The implication that because TypeScript compiles to JS which has no types and is therefore wrong is pure drivel.

Re: Reservations about TypeScript

#16

Post by rfw »

daviesgeek wrote: post #12
nkohari wrote: post #11

Earlier quoted context omitted.

That argument doesn't really make sense. The type system is a feature of the compiler, so why would the output of the compiler need to be aware of it? Lots of typed languages compile to machine language, which has no inherent type system. Compilers which do add type information into the output are usually paired with a runtime that uses it for things like late binding or dynamic dispatch, but JavaScript doesn't suppo…

All fair points and totally valid. My concern is the facade/promise of type security.

Forgive me if I misunderstand, I still don't understand your concern – TypeScript has type safety because it can check types at compile time (vs. JavaScript which has very limited type safety at run time). I don't think it's fair to call it a facade, because it is definitely commonly accepted as type safe.

Re: Reservations about TypeScript

#17

Post by anderskaseorg »

daviesgeek wrote: post #12
nkohari wrote: post #11

Earlier quoted context omitted.

That argument doesn't really make sense. The type system is a feature of the compiler, so why would the output of the compiler need to be aware of it? Lots of typed languages compile to machine language, which has no inherent type system. Compilers which do add type information into the output are usually paired with a runtime that uses it for things like late binding or dynamic dispatch, but JavaScript doesn't suppo…

All fair points and totally valid. My concern is the facade/promise of type security.

Your quarrel is not with JavaScript (as everyone else has pointed out, there’s no reason one can’t build a secure compile-time type system on top of JavaScript), but with some of the specific design decisions made by TypeScript that open soundness holes, such as “programmers are too stupid to understand the difference between covariance and contravariance, so we’ll pretend everything is bivariant”.

See https://www.typescriptlang.org/docs/handbook/type-compatibil... for a less cynical presentation of these design decisions.

Re: Reservations about TypeScript

#18

Post by 013a »

barakm wrote: post #8

> 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,…

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.

Re: Reservations about TypeScript

#19

Post by catnaroek »

barakm wrote: post #8

> 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,…

> 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.)

Re: Reservations about TypeScript

#20

Post by barakm »

013a wrote: post #18
barakm wrote: post #8

> 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,…

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 devel…

Good to know; if this were a stated reservation, that'd be worth writing about.
Post reply on HN