←back to thread

Skeptical of rewriting JavaScript tools in "faster" languages

(nolanlawson.com)
160 points todsacerdoti | 1 comments | 20 Oct 24 21:25 UTC | HN request time: 0.205s | source
Show context
jpalawaga ◴[20 Oct 24 21:53 UTC] No.41898791[source]▶
Anyone who has done a programming contest, advent of code, etc knows that the language doesn’t matter so much as your algorithm.

Yes, the language can bring a nice speed up, or might give you better control of allocations which can save a lot of time. But in many cases, simply picking the correct algorithm will deliver you most of the performance.

As someone who doesn’t JavaScript a lot, I’d definitely prefer a tool written in go and available on brew over something I need to invoke node and its environment for.

replies(12): >>41898816 #>>41898879 #>>41898890 #>>41898952 #>>41899000 #>>41899028 #>>41899401 #>>41901158 #>>41901185 #>>41901525 #>>41902030 #>>41904514 #
tyree731 ◴[20 Oct 24 21:56 UTC] No.41898816[source]▶
Lots of very smart people have worked very hard on Python tools written in Python, yet the rust rewrites of those tools are so much faster. Sometimes it really is the programming language.
replies(6): >>41898834 #>>41898859 #>>41898913 #>>41898949 #>>41899003 #>>41899226 #
1. charrondev ◴[20 Oct 24 22:04 UTC] No.41898859[source]▶
In the JavaScript world a lot of speed up comes from 3 major things as far as I can tell:

- easier concurrency. - the fact that things are actually getting rewritten with the purpose of speeding them up. - a lot of the JS tooling getting speedups deals with heavily with string parsing, tokenizing, generating and manipulation of ASTs. Being able to have shared references to slices of strings, carefully manage when strings are copied, and have strict typing of the AST nodes you enable things to be much faster than JavaScript.