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

161–170 of 252 posts

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

#161

Post by sealeck »

vips7L wrote: post #156
constexpr wrote: post #154

I'm the author of esbuild. I think this is a very smart, practical choice and is one of the approaches that has the best chance of succeeding (the other being a semi-automated porting tool instead of a purely manual port). I'm very excited to see someone take this approach. This is how I would do it if I were to do it. Web developers around the world are hoping this works out :) The hard part about this project isn't…

> the ability to easily add shared-memory parallelism I’m honestly not sure if there is any popular language where this isn’t true?

Python? JavaScript? Ruby?

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

#162

Post by constexpr »

msoad wrote: post #158
constexpr wrote: post #154

I'm the author of esbuild. I think this is a very smart, practical choice and is one of the approaches that has the best chance of succeeding (the other being a semi-automated porting tool instead of a purely manual port). I'm very excited to see someone take this approach. This is how I would do it if I were to do it. Web developers around the world are hoping this works out :) The hard part about this project isn't…

Unfortunately TypeScript is doing all of type-checking synchronously mostly due how it needs to build a global symbols list first. There are some hints that they might move towards more parallel processing but it requires a lot of major changes https://github.com/microsoft/TypeScript/issues/30235

Yeah I was afraid of that. Ideally it would be possible to do type checking in parallel at the function level or something, but TypeScript allows you to omit the return type and then infers the return type from the function body which adds additional dependencies and makes that more complicated to parallelize. I wonder if it would still be possible though. Maybe just for functions where the return type and all argument types are present? Then the approach would be sort of outside-in where you type check the unparallelizable global stuff serially first and then type check the remaining isolated function body stuff in parallel afterward.

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

#163

Post by sealeck »

scottlamb wrote: post #98
yazaddaruvala wrote: post #97

Earlier quoted context omitted.

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

It used to be in std.

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

#164

Post by Smaug123 »

travisd wrote: post #116
vosper wrote: post #94

Earlier quoted context omitted.

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

I haven’t personally benchmarked it, but I know it’s available as an eslint rule (all exported functions must have declared return types).

This makes sense for semantic reasons though. If you accidentally return a `number` when you returned a `string` in some earlier branch, Typescript will happily unify them and now your function silently returns `string | number`. The linting rule prevents this.

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

#165

Post by munificent »

throwaway894345 wrote: post #29
pjmlp wrote: post #25

The thing with all those projects is playing catch-up with upstream, and the possible variations from what is actually the official semantics depending on the TypeScript version.

Personally I wouldn't fret about keeping pace with upstream. Eventually the syntax will stabilize if it hasn't already. I'd be more worried about fidelity--does this produce the same result as the reference implementation? TFA says he's running against the "conformance" test suite, so that should keep things pretty tight and when bugs are found they'll be fixed in time and presumably the test suite will be updated ac…

> Eventually the syntax will stabilize if it hasn't already.

Every language in wide use today is still evolving and, if anything, it seems that the pace of language change is generally increasing.

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

#166

Post by throwaway894345 »

munificent wrote: post #165
throwaway894345 wrote: post #29

Earlier quoted context omitted.

Personally I wouldn't fret about keeping pace with upstream. Eventually the syntax will stabilize if it hasn't already. I'd be more worried about fidelity--does this produce the same result as the reference implementation? TFA says he's running against the "conformance" test suite, so that should keep things pretty tight and when bugs are found they'll be fixed in time and presumably the test suite will be updated ac…

> Eventually the syntax will stabilize if it hasn't already. Every language in wide use today is still evolving and, if anything, it seems that the pace of language change is generally increasing.

Some amount of evolution is fine, and I think your “pace of language change is increasing” may be true for some languages and time scales, but most languages don’t change more in their second five years than their first.

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

#167

Post by sapphyrus »

Maybe tsc already does this, but why not just make extensive use of caching to get the compile times for "incremental builds" under control? Why would it have to re-check all 10,000 files in my project just because I modified a single file? That seems way more manageable (and less error-prone) than rewriting the entire thing.

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

#168

Post by azakai »

scottlamb wrote: post #119
mrkentutbabi wrote: post #113

Earlier quoted context omitted.

What is the difference between porting and complete rewrite? I thought they are the same?

> What is the difference between porting and complete rewrite? I thought they are the same? As with so many terms in computing, there aren't universally agreed definitions. But in the author's post, I read "porting" as switching languages while changing as little as possible vs "complete rewrite" as redesigning/rearchitecting it along the way.

To add to that, I would say that simple forms of "porting" can be done without really understanding the overall architecture. You just need to understand each line (or a few lines around it) at a time. I understood the post to mean something like that, which sounds like a good plan here, to minimize the risk of adding bugs.

And in comparison, a "complete rewrite" would require a full understanding of the big picture design of the original code, come up with a perhaps different one in the rewrite, and keep the differences in your head as you go (or, forget about the original design entirely and solve it from scratch - and keep that in your head as you go). Far more work and risk, and it would have been a bad choice here.

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

#169

Post by rowanG077 »

Waterluvian wrote: post #75
hardwaregeek wrote: post #32

This reminds me of when people try to make a new Ruby implementation. They get the basics down and think "this isn't so bad! I can do this!". Fast forward a few months and they're stuck on some nasty little edge case around eval and method_missing that they need to run Rails. Or some weird aspect of C extensions. TypeScript's compiler is an unholy, unsound mess, because JavaScript is an unholy, unsound mess. Sure the…

I am absolutely blown away at how good TypeScript's type checker is, given how much of an unholy mess JavaScript is, and that the TypeScript language cannot just deprecate all the awful parts. More than once I've yelled at my screen, "HOW DO YOU KNOW THIS?!" about some inferred or narrowed type.

I'm the opposite. I was continually perplexed by trivial stuff that TypeScript just couldn't figure put. Maybe that has changed in the last year but I doubt it.

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

#170

Post by rslabbert »

vosper wrote: post #94
travisd wrote: post #40

Earlier quoted context omitted.

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?

I haven't found any large scale analyses but here's an example of a simple type annotation halving compilation time: https://stackoverflow.com/questions/36624273/investigating-l...

The Typescript compiler performance wiki might also be of interest: https://github.com/microsoft/TypeScript/wiki/Performance

Post reply on HN