News for hackers. Stuff that matters.
Re:TypeScript team released an explorer for performance tuning by josteink on Saturday May 13, 2023 @08:54AM (#35927918)
A benefit of the typescript compiler being written in typescript is that the compiler-makers get to dogfood their own language.

Rewriting it in rust would remove that important aspect c

Re:TypeScript team released an explorer for performance tuning by muglug on Saturday May 13, 2023 @09:10AM (#35928021)
Yeah, that helps them stay close to the community and prevents any air of superiority that can come from writing Rust.

But, while I’m sure it was really important initially, there are now very many test cases and early-adopters to help prevent regressions.

And they still have that large TypeScript codebase to test their new tool on — it wouldn’t vanish.

Re:TypeScript team released an explorer for performance tuning by AntonCTO on Saturday May 13, 2023 @09:08AM (#35928010)
Rust alone wouldn't help. TypeScript is very hard to compile and to understand because of its complexity. I think there is a need for a different architectural approach with huge parallelization. Some (CI) servers have plenty of cores. Heck, my laptop has 20 threads.
Re:TypeScript team released an explorer for performance tuning by wffurr on Saturday May 13, 2023 @09:51AM (#35928385)
swc and tsx are already significantly faster than tsc, partly due to being written in faster languages, or languages that make it easier to write fast code with minimal runtimes.
Re:TypeScript team released an explorer for performance tuning by AntonCTO on Saturday May 13, 2023 @09:56AM (#35928422)
Do they check types?

Sorry, my previous comment wasn't very clear. Of course, faster languages produce faster results. But the language alone isn't enough in this case.

Re:TypeScript team released an explorer for performance tuning by explaininjs on Saturday May 13, 2023 @11:28AM (#35929305)
Neither of those check types. It’s easy to be fast when all you’re doing is filtering out type-bytes (and perhaps some transpiling). That’s nothing compared to actually type checking, which requires solving complex satisfiability problems across the entire codebase.
Re:TypeScript team released an explorer for performance tuning by muglug on Saturday May 13, 2023 @04:19PM (#35932298)
My understanding was that TypeScript would be more parellisable than Flow, which itself is plenty parallelisable: https://arxiv.org/pdf/1708.08021.pdf
Re:TypeScript team released an explorer for performance tuning by explaininjs on Sunday May 14, 2023 @08:20PM (#35942625)
Call me crazy, but I prefer single threaded. It limits the potential impact on the rest of the system, and all cloud payment is by the core•hour anyways.
Re:TypeScript team released an explorer for performance tuning by muglug on Saturday May 13, 2023 @04:03PM (#35932170)
The approach is simple (I've implemented it, and so have many others):

It takes three steps. Steps 1 and 3 are parellisable, and 2 should be very quick:

1. Convert every file in the repository to an AST, and perform static reflection on that AST.

2. Calcuate the inheritance graph for all the functions, classes etc. you've collected

3. Analyse every file, using the pre-calculated list of functions and classes available in each case.

Re:TypeScript team released an explorer for performance tuning by wffurr on Saturday May 13, 2023 @09:50AM (#35928375)
Doesn’t seem worth the lost performance for the millions of Typescript users.
Re:TypeScript team released an explorer for performance tuning by HPsquared on Saturday May 13, 2023 @10:21AM (#35928708)
May give an incentive to improve the performance
Re:TypeScript team released an explorer for performance tuning by mort96 on Saturday May 13, 2023 @10:53AM (#35928972)
Which they'd have to do through rewriting it in a faster language.