Typescript compiles to javascript, so does this not prove what people have been screaming from the rooftops for so long that there's a significant performance penalty with typescript for almost no actual benefit?
> a significant performance penalty with typescript
There's a significant performance penalty for using javascript outside the browser.
I'm not aware of any JS runtime outside a browser that supports concurrency (other than concurrently awaiting IO), so you can't do parallel compilation in a single process.
It's generally also very difficult to make a JS program as fast as even a naive go program, and the performance tooling for go is dramatically more mature.
> I'm not aware of any JS runtime outside a browser that supports concurrency (other than concurrently awaiting IO), so you can't do parallel compilation in a single process.
You haven't looked very hard then, NodeJS has supported worker threads for years. However, to uphold Javascript's safety guarantees, they can only communicate via message passing, or sharing a special `SharedArrayBuffer` datatype, neither of which are well suited to sharing large immutable data structures.
Nope; 'compiling to javascript' is a relatively trivial operation, just remove the type information. This is what Babel and nowadays NodeJS itself are doing.
What is more important is that tsc does typechecking, which is a static analysis of sorts to ensure code correctness. But this has nothing to do with runtime performance, that's entirely in JS land and in JS transpilers / optimizers.
I don't think anyone uses JavaScript for speed. Dynamic or scripting languages have been making this tradeoff since... as long as there has been programming?
You seem to be referring to runtime performance of compiled code. The announcement is about compile times; it's about the performance of the compiler itself.
