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

I’m porting the TypeScript type checker tsc to Go

kdy1.dev

Post reply on HN
Print view View original

91–100 of 252 posts

Re: I’m porting the TypeScript type checker tsc to Go

#91

Post by resoluteteeth »

eyelidlessness wrote: post #77
nevir wrote: post #71

Super skeptical that porting this to a new language is going to have the kind of performance gains they expect ... assuming they want to replicate all of tsc's functionality

It’s already proven (esbuild, SWC, Bun) to drastically improve performance of TypeScript’s other responsibility: compilation (tsc doesn’t offer an option for this, but ts-node does, for comparison). And while the type checker is certainly more complex, I have a hard time imagining it won’t show similar improvements in a native language.

Compiling typescript is basically just stripping the type definitions/annotations and other typescript-specific parts of the syntax out. That's a huge difference from actually type checking it.

Re: I’m porting the TypeScript type checker tsc to Go

#92

Post by quickthrower2 »

paavohtl wrote: post #63
andreypopp wrote: post #30

Well... How many paid work hours spent on tsc? Then does TypeScript have a formal language specification? I'm pessimistic it's possible to rewrite tsc with full compat (bug-to-bug, otherwise it doesn't really make much sense) without MS support... but who knows... I'd like fast compiles too, so good luck!

A formal specification would be basically useless, if nothing guarantees that the reference implementation actually follows it. Sharing & contributing to the same test suite is a much more practical approach.

As a smoke you can swap it in for a lot of the npm ecosystem and run the tests of those projects on the compiled code.

Re: I’m porting the TypeScript type checker tsc to Go

#93

Post by anonymousCar »

jkelleyrtp wrote: post #85

TSC doesn't need to "stick around", right? Just a run-once and the program is over? In those cases, https://github.com/fitzgen/bumpalo works amazingly as an arena. You can pretty much forget about reference counting and have direct references everywhere in your graph. The disadvantage is that it's hard to modify your tree without leaving memory around. We use it extensively in http://github.com/dioxusLabs/dioxus and…

I think --watch mode means it's running while developing

Re: I’m porting the TypeScript type checker tsc to Go

#94

Post by vosper »

travisd wrote: post #40
danenania wrote: post #38

Earlier quoted context omitted.

If they focus on the core features and make a significant enough improvement, perhaps the core TS team could be convinced to pull it in as a native extension and make calls to it for the operations it covers? If something like 62x improvement is really achievable, it's hard to imagine the team not being interested at all. I would personally be very happy to use a significantly slimmed down subset of TypeScript if it…

To this point, many teams are already using subsets of TypeScript to improve compilation times. Often times it’s things like always declaring return types on functions to avoid the compiler having to infer it (especially between module boundaries). Calling this a “subset of typescript” might be strong wording, but it does suggest there is some desire in that general area.

> To this point, many teams are already using subsets of TypeScript to improve compilation times. Often times it’s things like always declaring return types on functions to avoid the compiler having to infer it (especially between module boundaries).

I hadn't heard of this trick - how much improvement does it make? Seems like it might be good for readability, too?

Re: I’m porting the TypeScript type checker tsc to Go

#95

Post by smasher164 »

I wonder how it would fare if instead of rewriting from scratch, they applied automated transformation from the Typescript source code to Go. It wouldn't have to capture all the semantics of TS/JS, but be opinionated enough to transform the Typescript source.

Another possibility is to use something like GraalVM native-image to compile Typescript's type-checker into a binary. This might offer a speedup over its execution on V8.

Re: I’m porting the TypeScript type checker tsc to Go

#97

Post by yazaddaruvala »

scottlamb wrote: post #53

The "why not port to Rust" part boils down to these paragraphs: > tsc uses a lot of shared mutability and many parts depend on garbage collection. Even though I’m an advocate and believer in Rust, it doesn’t feel like the right tool for the job here. Using Rust required me to use unsafe too much for this specific project. > tsc depends on shared mutability and has a cyclical mutable reference. Rust is designed to pre…

All of that is valid for a rewrite, but not efficient if you’re porting the current implementation.

As I understand it, in this case, Rust would be able to have a line to line port from JavaScript.

I do still think your overall point holds. Why not use a library in the Rust ecosystem to help with this problem e.g. some GC type.

Re: I’m porting the TypeScript type checker tsc to Go

#98

Post by scottlamb »

yazaddaruvala wrote: post #97
scottlamb wrote: post #53

The "why not port to Rust" part boils down to these paragraphs: > tsc uses a lot of shared mutability and many parts depend on garbage collection. Even though I’m an advocate and believer in Rust, it doesn’t feel like the right tool for the job here. Using Rust required me to use unsafe too much for this specific project. > tsc depends on shared mutability and has a cyclical mutable reference. Rust is designed to pre…

All of that is valid for a rewrite, but not efficient if you’re porting the current implementation. As I understand it, in this case, Rust would be able to have a line to line port from JavaScript. I do still think your overall point holds. Why not use a library in the Rust ecosystem to help with this problem e.g. some GC type.

> All of that is valid for a rewrite, but not efficient if you’re porting the current implementation.

Help me see it?

I can easily see how getting rid of the cyclical structure crosses from "line-to-line port" into "rewrite" territory. I'm not saying you're wrong, but I'm having more trouble seeing how "wrap some types in cells and pass along a lifetime and arena parameter" crosses that threshold. It might not be feasible at all, though, if tsc compilations are long-lived for language server + incremental compilation support.

> Why not use a library in the Rust ecosystem to help with this problem e.g. some GC type.

iirc I've seen some experimental GC library mentioned. I think something like that is at least off the beaten path enough that I can see how the author might decide it's better to just use Go instead.

Re: I’m porting the TypeScript type checker tsc to Go

#99

Post by connor4312 »

anonymousCar wrote: post #93
jkelleyrtp wrote: post #85

TSC doesn't need to "stick around", right? Just a run-once and the program is over? In those cases, https://github.com/fitzgen/bumpalo works amazingly as an arena. You can pretty much forget about reference counting and have direct references everywhere in your graph. The disadvantage is that it's hard to modify your tree without leaving memory around. We use it extensively in http://github.com/dioxusLabs/dioxus and…

I think --watch mode means it's running while developing

Additionally, the language server used to power editors is long lived. TypeScript isn't just the compiler.

Re: I’m porting the TypeScript type checker tsc to Go

#100

Post by chubot »

throw10920 wrote: post #34
petmon wrote: post #27

Earlier quoted context omitted.

Non-GC languages are bad in general at handling cyclical references (mutable or not), and Rust is especially ill suited for it because of the borrow checker. For example should an arbitrary reference in tsc become an rc::Rc or an rc::Weak? You have to tease out the implicit ownership model and one may not even exist. tsc was designed expecting GC and it makes perfect sense to port it to another fast GC language.

I'm not a Rust fanboy (in fact, I rather despise the RESF, especially given Rust's mediocre tooling), but: I think that "You have to tease out the implicit ownership model and one may not even exist" suggests a problem with the program itself . I can't think of any reason why a program must have an ill-formed ownership model (unlike, say, the fact that many interesting programs must have an embedded dynamic type syst…

If your program is an interpreter, then I think the ownership model is going to be dominated by the program being interpreted, not the intepreter itself... That is, has to be general enough to interpret any program, and many of those programs will have cyclic data structures.

TSC is not an interpreter, but its type system is Turing complete, so I wouldn't be surprised if it has some similar issues.

Post reply on HN