> Using the right abstractions (including the right number of abstractions) and the right data structures and algorithms is always going to trump the constants language choice can optimize.

I was with you until this paragraph, which is straight up incorrect. Language choice absolutely matters if your goal is performance.

The most obvious counterexample is that the TypeScript team pretty much did a direct port from TS to Golang, without significantly rewriting their core algorithms or changing their data structures, and it sped up the TS compiler by 10X, which is an enormous performance improvement that would be silly to dismiss as just a "constant." This is because JS is a bad choice of language for implementing a fast compiler, primarily due to its poor support for multithreading.

▲

conartist6 8 hours ago | parent [-]

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.