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

171–180 of 252 posts

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

#171

Post by charrondev »

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…

TSC supports both a watch mode and is used heavily as a language server.

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

#172

Post by cellularmitosis »

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.

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

#173

Post by epolanski »

endgame wrote: post #111
epolanski wrote: post #104

Earlier quoted context omitted.

Just today I was triggered that this compiles. declare foo: never[] // it can only be an empty array foo[1] // compiles TypeScript is a nice type system, it's surprisingly expressive and flexible, like e.g. in Haskell I was surprised that there's this strange notion that for a given type you can only have one `Eq` or `Ord` instance for some type A. But in TypeScript you can have as many Ord interfaces as you want. I…

> you can only have one `Eq` or `Ord` instance for some type A. This is a good thing - it stops you from using one Ord instance when putting As into a Map or Set, and then trying to pull them back out using another. Newtypes let you provide "additional" instances in a safe way.

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.

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

#174

Post by lockyc »

rowanG077 wrote: post #169
Waterluvian wrote: post #75

Earlier quoted context omitted.

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.

Do you have examples?

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

#175

Post by lprd »

peterangular wrote: post #135
epolanski wrote: post #102

I'm not so positive about these projects. They are good willed but TypeScript doesn't have an official spec, it's an implementation-defined language. It's not C, it's not JavaScript, it's whatever each release wants it to be. This makes it very difficult to follow every version and evolution, you're consistently chasing whatever has been merged on release.

And it's the exact reason I'm really reluctant to fully buy into Typescript... I always feel like I'm wrong about the "not an official spec" part of things but you are 100% correct in my understanding. Also on "it's whatever each release wants it to be" - that is hell on earth if you're looking to target consistent software processes and it only gets worse the more you scale (both solution and team). I get the value…

I share the same concerns. It’s also a little irking that if I want to enjoy good tooling for typescript, I now have to install another language on my system since the language that typescript sits on is a hot mess. I don’t mean to cast shame on JavaScript, but I’d be remiss to not say that modern js development is a bit insane. The only reason we all go along with it is because we have to.

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

#176

Post by steveklabnik »

newlisp wrote: post #126
scottlamb wrote: post #54

Earlier quoted context omitted.

> Sure but this goes against "Don't communicate by sharing memory", no? Yes, but that's advice rather than something Go requires. It's reasonable to say it's outweighed by the desire to avoid significantly restructuring the existing logic. The author is explicitly choosing to match the upstream program's structure to limit the project scope, and whether that structure is good or not is almost besides the point. btw:…

Curious, can you elaborate on what are the issues of mutability in single-threaded code?

https://manishearth.github.io/blog/2015/05/17/the-problem-wi...

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

#177

Post by epolanski »

acid__ wrote: post #155
epolanski wrote: post #104

Earlier quoted context omitted.

Just today I was triggered that this compiles. declare foo: never[] // it can only be an empty array foo[1] // compiles TypeScript is a nice type system, it's surprisingly expressive and flexible, like e.g. in Haskell I was surprised that there's this strange notion that for a given type you can only have one `Eq` or `Ord` instance for some type A. But in TypeScript you can have as many Ord interfaces as you want. I…

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.

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

#178

Post by ameliaquining »

pjmlp wrote: post #129
newlisp wrote: post #112

Earlier quoted context omitted.

The author of esbuild also started the implementation of esbuild in rust, found it painful too and switched to build it in go.

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 performance wall that I can't climb over.

That being said, porting this kind of codebase to Rust would indeed be really rough—definitely possible, but by no means pleasant. I like to think the platonic ideal Rust, which we're hopefully getting closer and closer to over time, is capable of elegantly handling cyclic data structures and the like even while encouraging a single-ownership model for the 95% of cases where that's the right design. I don't think the Rust we have today is there yet.

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

#179

Post by halpert »

reuben364 wrote: post #143
dmitriid wrote: post #87

Earlier quoted context omitted.

However, more than once I've also yelled "HOW DO YOU NOT KNOW THIS?!" at something or other :)

I've managed to get the compiler to typecheck const x: Thing = exprA; const y: Thing = exprB; const z = [x, y]; but somehow not: const z: Thing[] = [exprA, exprB]; although exprA and exprB were pretty nasty typing wise.

Where you trying to create a tuple? Does `const z: [Thing, Thing] = [exprA, exprB];` work?

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

#180

Post by kaba0 »

Slightly off topic, but do I not get something about Go? It comes up waay to often nowadays here, perhaps even more than LISPs - last time Rust was the hyped one, but it seemed to have decreased a bit. But at least rust is an interesting language with some novel features, adding new value to the low level PL domain. I fail to see what is unique about Go, other than the perhaps least known non-blocking concurrency (based on the recent “invisible” article on this). I find the simplicity of it (with the often claimed reason being basically “code monkeys not hindering each other’s work”, quite offending) really off-puttingz
Post reply on HN