Earlier quoted context omitted.
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.
This is interesting but I don't know Rust. Presumably your graph data structure grows dynamically, meaning you have to add nodes at runtime. When. you say you can't mutate the same data structure more than once at runtime, what does it mean? That you can't set both a parent and a child pointer in the same function, or what?
I’m porting the TypeScript type checker tsc to Go
151–160 of 252 posts
Re: I’m porting the TypeScript type checker tsc to Go
#152Earlier quoted context omitted.
It’s already proven (esbuild, SWC, Bun) to drastically improve performance of TypeScript’s other responsibility: compilation (tsc doesn’t offer an option for this, but ts-node does, for comparison). And while the type checker is certainly more complex, I have a hard time imagining it won’t show similar improvements in a native language.
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.
Re: I’m porting the TypeScript type checker tsc to Go
#153Earlier 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 wouldn't expect never[] to mean 0 length array, tbf. It's a variable length array of _type_ never. It should be something akin to: declare foo: never[0];
Re: I’m porting the TypeScript type checker tsc to Go
#154The hard part about this project isn't doing the port but keeping up with the constant changes from the TypeScript team, especially if the TypeScript team isn't invested in helping you out. Staying as close as possible to the source language like this will be a big win there.
One of the big benefits of a native language like Go aside from lack of a JIT is the ability to easily add shared-memory parallelism. I haven't studied the TypeScript compiler internals so I'm not sure how easy it is to parallelize their type checker. However, I assume that it would be relatively straightforward to parallelize the parsing of JavaScript files, so I'd hope for at least be a big speedup there.
Re: I’m porting the TypeScript type checker tsc to Go
#155Earlier quoted context omitted.
However, more than once I've also yelled "HOW DO YOU NOT KNOW THIS?!" at something or other :)
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…
https://www.typescriptlang.org/play?#code/CYUwxgNghgTiAEYD2A...
Re: I’m porting the TypeScript type checker tsc to Go
#156I'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…
I’m honestly not sure if there is any popular language where this isn’t true?
Re: I’m porting the TypeScript type checker tsc to Go
#157Earlier 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).
Re: I’m porting the TypeScript type checker tsc to Go
#158I'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…
Re: I’m porting the TypeScript type checker tsc to Go
#159I'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?
Re: I’m porting the TypeScript type checker tsc to Go
#160Earlier 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.
Doesn't
const z = [exprA, exprB] as const;
type GnarlyThingTuple = typeof z;
or something like this help?