I’m porting the TypeScript type checker tsc to Go
1–10 of 252 posts
Re: I’m porting the TypeScript type checker tsc to Go
#2Re: I’m porting the TypeScript type checker tsc to Go
#3I'm happy to see this, as honestly I don't really understand why you would compile TS without type checking.
Re: I’m porting the TypeScript type checker tsc to Go
#4go means it's going to be easier to integrate to esbuild :) I'm happy to see this, as honestly I don't really understand why you would compile TS without type checking.
I don't think I'm remotely alone in doing this but I'll share from my perspective. I have two modes while writing TypeScript stuff: 1) prototyping something where I don't want to spend time writing types (or maybe I write some types but I don't care if they are correct or line up yet) but I still want to have JavaScript generated so I can test the thing out manually and 2) getting types correct as part of long-term maintenance and edge-case removal.
There are fast TypeScript -> JavaScript generators today like swc and esbuild. tsc is not fast. So I can speed up "1)" from above if I use swc and esbuild and only use tsc for "2)" from above.
As people write faster implementations of tsc-the-type-checker though I'll be happy to use that instead and just not use tsc anymore.
Re: I’m porting the TypeScript type checker tsc to Go
#5go means it's going to be easier to integrate to esbuild :) I'm happy to see this, as honestly I don't really understand why you would compile TS without type checking.
Re: I’m porting the TypeScript type checker tsc to Go
#6Re: I’m porting the TypeScript type checker tsc to Go
#7Strange reasoning.
Re: I’m porting the TypeScript type checker tsc to Go
#8tsc relies in shared state and is slow, so they port it to a language that allows shared state. Strange reasoning.
Sure, if you absolutely wish it to, in an `unsafe` block, you can define two writeable pointers to the same piece of data. I don't think I've ever seen anybody write such code in Rust (except perhaps when linking to a C library that required it?), nor have I ever felt the need to do so.
Now, it is true that Rust is designed to discourage writing cyclic data structures. I can imagine that trying to port (rather than redesign) an algorithm that deeply requires cyclic data structures, that will make your life miserable.
Re: I’m porting the TypeScript type checker tsc to Go
#9tsc relies in shared state and is slow, so they port it to a language that allows shared state. Strange reasoning.
(er, some text in the parent seems to have vanished) Sure, if you absolutely wish it to, in an `unsafe` block, you can define two writeable pointers to the same piece of data. I don't think I've ever seen anybody write such code in Rust (except perhaps when linking to a C library that required it?), nor have I ever felt the need to do so. Now, it is true that Rust is designed to discourage writing cyclic data structu…
Re: I’m porting the TypeScript type checker tsc to Go
#10go means it's going to be easier to integrate to esbuild :) I'm happy to see this, as honestly I don't really understand why you would compile TS without type checking.
> I'm happy to see this, as honestly I don't really understand why you would compile TS without type checking. I don't think I'm remotely alone in doing this but I'll share from my perspective. I have two modes while writing TypeScript stuff: 1) prototyping something where I don't want to spend time writing types (or maybe I write some types but I don't care if they are correct or line up yet) but I still want to hav…
It doesn't compile to JS, but this is one of the canonical use cases for Stanza 's (1) "optional" type system