Absolutely agree. If a JS developer doesn't know Rust, Go, Zig, or something, then they probably aren't going to do a good job at maintaining critical infrastructure, even if it were written in JS.

Why are people writing "critical" infrastructure in JS anyway, it is the wrong tool for the job.

▲

jmull a day ago | parent [-]

Why are people writing critical infrastructure in [any language]?

In reality, the tools this article is referring to were written in javascript because they could be and it was the best tool for the job (according to the people who matter: the people who did the work).

If someone wants to rewrite them for speed and/or to chase the next shiny language, that's fine with me, but let's not kid ourselves that there was something wrong with using javascript in the first place.

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.

▲

theowaway213456 a day ago | parent [-]

> 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 16 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 12 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 11 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.