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

11–20 of 252 posts

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

#11

Post by Yoric »

wizzwizz4 wrote: post #9
Yoric wrote: post #8

Earlier quoted context omitted.

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

You actually can't define two `&mut` references to the same data in Rust. It's invalid Rust code; if the compiler notices, it'll refuse to compile, and if it doesn't notice, your code will randomly break.

You can define two `*mut`, though, in unsafe code.

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

#12

Post by postalrat »

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.

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

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

#14

Post by jerf »

k__ wrote: post #7

tsc relies in shared state and is slow, so they port it to a language that allows shared state. Strange reasoning.

It sounds like you think "tsc is slow" because "it uses shared state". If that is what you're getting at, you've connected two unconnected statements.

It does tend to imply the new tsc isn't going to be able to take much more advantage of concurrency than the current one, which may put a limit on what performance gains it can expect. I don't know if the current tsc is able to do anything concurrently. (Here, "concurrently" doesn't merely mean "able to have multiple events in flight and thus do multiple tasks at the same 'time'" but truly "doing work on multiple CPUs simultaneously".) Go is generally faster than Node, but it'll be hard to guess by how much in this case.

A Rust port would be harder but would probably lead on in a direction to improve the concurrency. However, that may be an infeasible amount of work, not because of Rust per se but because a port is intrinsically easier than a port and a rearchitecting.

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

#15

Post by munificent »

k__ wrote: post #7

tsc relies in shared state and is slow, so they port it to a language that allows shared state. Strange reasoning.

The reasoning is only strange if you assume that the cause of slowness is the shared state.

CPUs have no problems with mutability. JS is slow because of dynamic typing, dispatch, flexible object layout, and an object model that requires lots and lots of heap allocation and pointer chasing.

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

#16

Post by tshaddox »

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…

Out of curiosity, how often do you have a project in the first mode that gets large enough that the speed of compiling TS to JS is significant?

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

#17

Post by anderskaseorg »

Yoric wrote: post #11
wizzwizz4 wrote: post #9

Earlier quoted context omitted.

You actually can't define two `&mut` references to the same data in Rust. It's invalid Rust code; if the compiler notices, it'll refuse to compile, and if it doesn't notice, your code will randomly break.

You can define two `*mut`, though, in unsafe code.

A better option is to use Cell or RefCell; they allow completely safe shared mutability in single-threaded code.

https://doc.rust-lang.org/std/cell/

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

#18

Post by eatonphil »

tshaddox wrote: post #16
eatonphil wrote: post #4

Earlier quoted context omitted.

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

Out of curiosity, how often do you have a project in the first mode that gets large enough that the speed of compiling TS to JS is significant?

There is a huge difference even in small and mid-size projects.

https://datastation.multiprocess.io/blog/2021-11-13-benchmar...

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

#19

Post by jupp0r »

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

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

#20

Post by mattkrick »

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.

Personally, I let vscode do typechecking on open files & have a pre-commit git hook to typecheck changed files.

When it comes to starting up a development server & building the client, there's a huge cost to repeatedly typechecking the same 1000+ files. By cutting out typechecking & only compiling, I can reduce the webpack client build from 40 seconds to 3 seconds (using sucrase).

Post reply on HN