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

211–220 of 252 posts

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

#211

Post by pjmlp »

ameliaquining wrote: post #178
pjmlp wrote: post #129

Earlier quoted context omitted.

For me the ideal use case for Rust is really for places where automatic memory management is a hard sell, even if technically possible, kernels, drivers, hypervisors, firmware, GPGPU, ... For everything else I rather enjoy the productivity of automatic memory management.

My general inclination is to go straight to Rust if I already tried a different reasonably performant language (like Node.js) and it wasn't fast enough—because only Rust (and C and C++ and a few more obscure languages) guarantees that basically any performance optimization that I might want to do will at least be possible , even if it might be inelegant or unsafe. I don't want to run the risk of hitting another perfo…

I wouldn't put node.js and performance on the same sentence.

Better than other dynamic languages, definitely. That is about it.

Plenty of languages that offer AOT compilation and automatically managed memory to chose from.

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

#212

Post by pjmlp »

cellularmitosis wrote: post #172
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.

If OP delivers on the preliminary 62x speed up, how could upstream justify not jumping ship to OP’s implementation? Certainly the user base will demand it.

Being Microsoft, they would rather make use of their Typescript compiler for IoT, yet they haven't.

https://makecode.com/language

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

#213

Post by afiori »

Nullabillity wrote: post #185
epolanski wrote: post #173

Earlier quoted context omitted.

Why shouldn't I be able to use as many Ord instances as I want? I'll give you a trivial example I have some data type representing a TvShow, why should there be just one way to sort a collection of TvShow? Maybe I want to sort by year, maybe by length, maybe by category. It's trivial to do in fp-ts, you can have as many Ord instances as you wish.

Ord is for the natural (obvious and hopefully uncontroversial) ordering of a given type. If your type doesn't have a natural ordering (as your TvShow doesn't) then you would use sortBy to supply an arbitrary compare function (just like what you would define in your Ord instance).

the argument is that usually you do not want that, it is a Haskell typeclasses vs ocaml modules discussion

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

#214

Post by afiori »

epolanski wrote: post #177
acid__ wrote: post #155

Earlier quoted context omitted.

I believe the type you're looking for is `[]` (a tuple with no elements) instead of `never[]`. https://www.typescriptlang.org/play?#code/CYUwxgNghgTiAEYD2A...

Yes I know, but `never[]` should also be unaccessible by index since it can never have any value.

variable length arrays are accessible at all indexes,

const a = foo[1]

should result in a bring of type `never|undefined` or `undefined` depending on flow analysis

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

#215

Post by chakkepolja »

morelisp wrote: post #59
mattkrick wrote: post #20

Earlier quoted context omitted.

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

What if not everyone else on your team is paying attention to their editor's warnings? What if the LS's async response doesn't come fast enough? What if, god forbid, you have to change something on a different computer? If it's not in your CI/CD scripts, it's not actually getting checked. > I can reduce the webpack client build... to 3 seconds This is about 10x longer than any interaction with a computer should be.

> If it's not in your CI/CD scripts, it's not actually getting checked.

You can make a similar argument and say you must write in a sound type system language, and TS typesystem is unsound.

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

#216

Post by pjmlp »

simplify wrote: post #55
scotty79 wrote: post #47

Earlier quoted context omitted.

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.

You're vastly underestimating the advanced type system features TypeScript requires to typecheck even the most basic JavaScript code. It would be more like 10% rather than 98%. Intersection and union types are no joke, and are notoriously difficult to make performant.

I just saw an example where the upcoming 4.6 will improve the clever use of recursive types done by some libraries.

Give the people a turing complete type system and they will write a complete application with it.

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

#217

Post by spion »

atom_arranger wrote: post #210
spion wrote: post #144

Earlier quoted context omitted.

Webpack does way more than esbuild, including running a typechecking compiler instead of just transpiling, running compilers able to downlevel emit to ES5 and providing a deep plugin architecture allowing you to hook into any bit you like. But yes, it hasn't been designed with speed in mind - it has been designed for maximum extensibility instead. Its the same reason why Babel is slow compared to sucrase (written in…

62X is still one order of magnitude. I would bet on a port eventually being done and hitting at least 10X.

Well we have some intersection then, I think it will be 10x at most :)

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

#219

Post by lucian1900 »

eyelidlessness wrote: post #152
resoluteteeth wrote: post #91

Earlier quoted context omitted.

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.

And yet, it’s drastically slower in JavaScript than in Go, Rust and Zig. I realize different algorithms will optimize differently between JS and native code, but I sincerely doubt tsc is anywhere near optimal speed.

That's mostly because tsc's parser is used by the JS implementations.

Writing a parser for the purpose would achieve performance closer to the other implementations.

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

#220

Post by morelisp »

chakkepolja wrote: post #215
morelisp wrote: post #59

Earlier quoted context omitted.

What if not everyone else on your team is paying attention to their editor's warnings? What if the LS's async response doesn't come fast enough? What if, god forbid, you have to change something on a different computer? If it's not in your CI/CD scripts, it's not actually getting checked. > I can reduce the webpack client build... to 3 seconds This is about 10x longer than any interaction with a computer should be.

> If it's not in your CI/CD scripts, it's not actually getting checked. You can make a similar argument and say you must write in a sound type system language, and TS typesystem is unsound.

Sorry, I don't understand the analogy. Yes, TS allows some bugs through, and that's a problem too. But that's also a far cry from "always rely on humans to run complex processes in a consistent way."
Post reply on HN