Earlier quoted context omitted.
And then you face Go's usual awkward issues with having a lack of generics which becomes important when, say, traversing a tree.
Thankfully that will end next month.
Truthfully I'm not looking forward to it.
I’m porting the TypeScript type checker tsc to Go
201–210 of 252 posts
Re: I’m porting the TypeScript type checker tsc to Go
#202[deleted]
Re: I’m porting the TypeScript type checker tsc to Go
#203Slightly 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 (ba…
Personally, I think the appeal of Go has much more to do with the compiler and the tooling than the language.
The compiler is blazing fast and you get small fast statically linked executables by default. That's very appealing to me even though the language itself is a bit spartan.
Re: I’m porting the TypeScript type checker tsc to Go
#204Earlier 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.
In my 5+ years introducing TypeScript everywhere that my team has to use JavaScript, this is almost always because JavaScript is an insane language that allows many counterintuitive things.
TS is sometimes weird because it is a superset of JS and has to be compatible.
Re: I’m porting the TypeScript type checker tsc to Go
#205> The more code you have, the longer it takes to compile. On medium-to-large-sized TypeScript projects, this compilation is extremely slow.
Or you could, you know, use the JS typechecker already built with large scale performance in mind (and in native language) - Flow.
I know Flow hasn’t had the bandwith to invest in supporting open source, and Typescript pretty much “won”, and there is now a large amount of library definitions without Flow support, but: If your codebase is large enough to suffer from TS’s architecture, you might have the resources to deal with the hurdles of adopting Flow. Flow still has some better designs such as nullables (?T).
That said, Flow is now being heavily optimized for large, strictly typed codebase, which means there is now no typechecker geared towards checking JS with minimal type annotations. I think that would still be useful for the prototyping stage of a project.
Re: I’m porting the TypeScript type checker tsc to Go
#206Just from a week ago on HN: I'm making a Typescript type-checker in Rust: https://news.ycombinator.com/item?id=30033119
Next week it will be Zig then
Re: I’m porting the TypeScript type checker tsc to Go
#207Earlier quoted context omitted.
What is the difference between porting and complete rewrite? I thought they are the same?
> What is the difference between porting and complete rewrite? I thought they are the same? As with so many terms in computing, there aren't universally agreed definitions. But in the author's post, I read "porting" as switching languages while changing as little as possible vs "complete rewrite" as redesigning/rearchitecting it along the way.
If that's the case, it seems unlikely that they'll be able to get the hoped for performance improvements
Re: I’m porting the TypeScript type checker tsc to Go
#208I'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…
love esbuild, ditched webpack and rollpack since then. been a fan of golang too since then.
Re: I’m porting the TypeScript type checker tsc to Go
#209> The more code you have, the longer it takes to compile. On medium-to-large-sized TypeScript projects, this compilation is extremely slow. Or you could, you know, use the JS typechecker already built with large scale performance in mind (and in native language) - Flow. I know Flow hasn’t had the bandwith to invest in supporting open source, and Typescript pretty much “won”, and there is now a large amount of library…
Last time I heard news about Flow was facebook/jest replacing it with TypeScript.
Re: I’m porting the TypeScript type checker tsc to Go
#210Earlier quoted context omitted.
esbuild is > 125x faster than Webpack, doing the exact same job. It's not some theoretical microbenchmark, you'll see it when converting a project from one to the other. If a software hasn't been designed with speed in mind, and I don't think tsc has, there can be massive performance improvements possible if you create a new implementation with performance as a top goal.
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.