←back to thread

Skeptical of rewriting JavaScript tools in "faster" languages

(nolanlawson.com)
160 points todsacerdoti | 10 comments | 20 Oct 24 21:25 UTC | HN request time: 0.809s | source | bottom
Show context
noname120 ◴[20 Oct 24 22:04 UTC] No.41898858[source]▶
> I just don’t think we’ve exhausted all the possibilities of making JavaScript tools faster

Rewriting in more performant languages spares you from the pain of optimization. These tools written in Rust are somehow 100× as fast despite not being optimized at all.

JavaScript is so slow that you have to optimize stuff, with Rust (and other performant languages) you don't even need to because performance just doesn't bubble up as a problem at all, letting you focus on building the actual tool.

replies(6): >>41898915 #>>41898923 #>>41898937 #>>41898975 #>>41901141 #>>41901628 #
1. ignoramous ◴[20 Oct 24 22:13 UTC] No.41898923[source]▶
Being a statically-typed compiled language has its perks (especially when doing systems programming). Regardless, JS runtimes can and will push forward (like JVM / ART did), given there's healthy competition for both v8 & Node.
replies(1): >>41898947 #
2. noname120 ◴[20 Oct 24 22:16 UTC] No.41898947[source]▶
JavaScript, Python, Lua, I don't see any dynamic language with good performances. Do you have examples?
replies(4): >>41898978 #>>41898999 #>>41899446 #>>41900448 #
3. dkersten ◴[20 Oct 24 22:22 UTC] No.41898978[source]▶
Lua with LuaJIT has pretty good performance. With that said, I spent today writing in C++, so I do agree with the overall sentiment.
replies(1): >>41905458 #
4. metadat ◴[20 Oct 24 22:26 UTC] No.41898999[source]▶
"Good" compared to what? All the mentioned languages keep getting more performant year-over-year, but in the medium future scripting languages are unlikely to reach the performance levels of C, Rust or other low-level languages.

Wouldn't it be amazing though? Maybe some combination of JIT and runtime static analysis could do it.

Personally, I never assign different types to the same variable unless it's part of a union (e.g. string | HTMLObject | null, in JS).

It would probably require getting rid of `eval' though, which I am fine with. On average, eval() tends to be naughty and those needs could be better met in other ways than blindly executing a string.

5. BoingBoomTschak ◴[20 Oct 24 23:37 UTC] No.41899446[source]▶
Common Lisp (SBCL)?
replies(1): >>41901006 #
6. EasyMark ◴[21 Oct 24 03:32 UTC] No.41900448[source]▶
Javascript is screamingly fast compared to the vast majority of other dynamic languages (scripting type, not something like Objective C). This is with the V8 engine of course. I’m not sure where you’re getting that it’s slow?
7. bitwize ◴[21 Oct 24 05:47 UTC] No.41901006{3}[source]▶
Don't forget Scheme (Gambit, Chez, Racket).
replies(1): >>41901139 #
8. BoingBoomTschak ◴[21 Oct 24 06:11 UTC] No.41901139{4}[source]▶
That's true, though I'd argue these are not as dynamic.
9. jart ◴[21 Oct 24 15:54 UTC] No.41905458{3}[source]▶
Then normal Lua by itself would probably be fastest for you. Nothing makes me happier than writing native extensions for Lua. Its C API is such a pleasure to work with. With Python and JavaScript, writing native extensions is the worst most dismal toil imaginable, but with Lua it's like eating dessert. So if you know both Lua and C++ really well, then you're going to be a meat eating super programmer who builds things that go really fast.
replies(1): >>41907349 #
10. kukkamario ◴[21 Oct 24 19:11 UTC] No.41907349{4}[source]▶
I prefer using Python with pybind11. It makes writing new modules or embedding the whole interpreter quite simple.