eslint is also a good example why Javascript runtime is bad choice for static analysis tools. The biggest problem is that it's single threaded.
Recent release of concurrency mode in eslint promised approximately 30% linting speed increase.
So now it uses multiple threads instead of one, and you got only 1.3x improvement. In any compiled language like Rust or Go you should expect time improvement that correlates with number of CPU cores engaged.
You can use worker threads in JS, but unfortunately sharing data between threads in context of static analysis, where there is a lot of deeply nested objects (AST) or basically a lot of data in general, is slow because it needs to be serialised and deserialised when it's passed between threads.
Javascript based tools for codebases with 1m+ lines of code becomes unusable :/
Recent release of concurrency mode in eslint promised approximately 30% linting speed increase.
So now it uses multiple threads instead of one, and you got only 1.3x improvement. In any compiled language like Rust or Go you should expect time improvement that correlates with number of CPU cores engaged.
You can use worker threads in JS, but unfortunately sharing data between threads in context of static analysis, where there is a lot of deeply nested objects (AST) or basically a lot of data in general, is slow because it needs to be serialised and deserialised when it's passed between threads.
Javascript based tools for codebases with 1m+ lines of code becomes unusable :/