I still think that rewrite was ill-advised. Yes they got a 10x speedup, but now it's unclear whether the JS tooling ecosystem lives in Go or Rust or JS.

Given that we've now got a three way language schism, the story for sharing data between processes isn't really solved. Data can move nicely within Go, but not between Go and Rust or JS. Tools like ts-morph also got left behind with no replacement.

I think that in retrospect the power of the JS ecosystem was all about plugins. It's plugins that make ESLint such a powerful platform that it still can't be replaced.

From the perspective of making a efficient platform for running plugins, JS actually is the most theoretically efficient implementation language! That's why, for example, VSCode put a bunch of work into moving its core state from C++ to JS, a change which brought them big perf wins and helped them beat out Atom: https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r...

▲

devilsdata 4 hours ago | parent [-]

What do you mean when you say the "story for sharing data between processes isn't really solved"? My understanding of this is mostly academic because I don't personally mix languages all that often, but aren't there many established ways of communication between languages. You have IPC, unix sockets, FFI, protobufs, and other serialising/deserialisation formats. Not to mention the classic (but probably slightly overkill) move of spinning up a local HTTP server and using REST endpoints.

	▲	conartist6 2 hours ago \| parent [-]
		Yes, all those ways exist. I was more saying that if copying between structures processes using serialization is all you need, the JS ecosystem already has that. The thing is if you need to do big expensive copies on the input or output it forces you towards a batch processing model, which is the opposite of incremental computation.