In this case, I'm concerned that they're particularly naive to think that writing only parts of ESLint in Rust will be a win. My impression -- no firsthand exp

In this case, I'm concerned that they're particularly naive to think that writing only parts of ESLint in Rust will be a win. My impression -- no firsthand experience -- is that the ser/des costs associated with FFI between node and rust when dealing with large objects like ASTs can eliminate most wins, especially if you have to go back and forth multiple times. Related: https://zaplib.com/docs/blog_post_mortem.html https://zaplib.com/docs/blog_post_mortem.html I'm also under the impression that most of the gains from rewriting Node into Go or Rust come from getting access to multithreading, which I can't imagine working well in this context if the ESLint plugins themselves are still written in JS (which, IMO, they certainly should be). A single file will still need to run on a single thread. (Of course, you can run different files on different cores with Workers or just subprocesses, but I assume ESLint does this already)