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

41–50 of 252 posts

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

#41

Post by Rowern »

danenania wrote: post #38
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…

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…

The issue here is that if you're running in the JS ecosystem you'll definitely want to use other people code (npm package or internal lib), if the subset breaks JS compatibility then you can break a significant amount of code without realising, if it is "only" a TS subset, then you need to make sure that each lib/package you import are compatible. Anyway this does not seem like a good solution.

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

#42

Post by recursive »

pjmlp wrote: post #22
postalrat wrote: post #12

Earlier quoted context omitted.

You compile ts without type checking when the options to do so are 10x+ faster than with type checking.

I really don't get this, when I save my TS files they are already compiled into JS on the fly, ready to fed into a .

By what? What if they were updated from an upstream repo, and never saved from an editor? What if you change branches without an upstream repo?

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

#43

Post by msoad »

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…

There is no specs so TypeScript's own impelemtption might not be accurate to what the team imagined on how things should work.

That means if this implementation passes all TypeScript's tests, it is as good as TypeScript.

Each new issue that is opened in either repo that shows discrepancy can be a new unit test added to the TypeScript codebase.

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

#44

Post by speedgoose »

jupp0r wrote: post #19

> tsc depends on shared mutability and has a cyclical mutable reference. Rust is designed to prevent this behavior. Having two references to the same data (shared mutability) is undefined behavior in Rust. This problem has numerous solutions in Rust - (A)Rc, RefCell etc. I don't understand how this caused the author of the article to stop considering Rust.

I think the point is valid. As a rust beginner I tried to make a graph data structure and it was difficult. Using RefCell is not very nice because it moves the problem from compile time to runtime and you still can’t mutate the same data structure more than once at the same time.

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

#45

Post by forty »

eatonphil wrote: post #4
forty wrote: post #3

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

That makes sense, I would generally use JS directly for mode 1), but I understand the use case.

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

#46

Post by fault1 »

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.

It seems like depending on how you configure typescript (e.g, in tsconfig), typescript is already something like an ensemble of mini-languages with different dialects and semantics. Much more so than other languages. But I agree, restricted typescript that has to do less work (data or control flow analysis) would probably be on the orders of magnitude faster.

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

#47

Post by scotty79 »

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…

Good thing is that the only thing it does is type-checking. So if you miss some edge case it won't influence at all how your ts code works.

The only thing is it may not catch some type error, which JS already does none of and TS can skip wherever you want or even implicitly and people are fine with that.

If I get 98% of TS typechecking 10 times faster. It's a huge win.

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

#49

Post by forty »

forty wrote: post #3

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

Answering to myself, a colleague suggestion (from tsc doc actually): use tsc --noEmit (for type checking) and a fast compiler.

tsc --noEmit duration is 2/3 of a normal build on our fairly large code base, so that can definitely speeds things up (for CI for example)

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

#50

Post by [deleted] »

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…

[deleted]
Post reply on HN