Skeptical of rewriting JavaScript tools in "faster" languages

> 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.

>JavaScript is so slow that you have to optimize stuff

This raises the question, is JavaScript more prone to premature optimization?

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.

Well, can we really call it premature optimization if it's needed?

Someday soon I hope webasm gets another decent compiled language targeted for JS speedups. Something interoperable with JS.

For analogies, look no further than ASM in the early days and the motivations that brought us C, but with the lessons learned as well.

Rust is fine for this, except for interoperability.

JavaScript, Python, Lua, I don't see any dynamic language with good performances. Do you have examples?

It looks like Rust can interop with JS via WebASM?

https://stackoverflow.com/questions/65000209/how-to-call-rus...

I think there’s a lot of bias in the samples one tends to see:

- you’re less likely to hear about a failed rewrite

- rewrites often gain from having a much better understanding of the problem/requirements than the existing solution which was likely developed more incrementally

- if you know you will care about performance a lot, you hopefully will think about how to architect things in a way that is capable of achieving good performance. (Non-cpu example: if you are gluing streams of data with processing steps together, you may not think much about buffering; if you know you will care about throughput, you will probably have to think about batching and maybe also some kind of fan-out->map->fan-in; if you know you will care about latency you will probably think about each extra hop or batch-building step)

- hopefully people do a bit of napkin math to decide if rewriting something to be faster will achieve the goals, and so you only see the rewrites that people thought would be beneficial (because eg you’re touching a lot of memory so a better memory layout could help)

I feel like you’re much more likely to see ‘we found some JavaScript that was too useful for its own good, figured out how to rewrite it with better algorithms/data structures, concurrency, and sims instructions, which we used rust to get’ than ‘our service receives one request, sends 10 requests to 5 different services, collects the results and responds; we rewrote it in rust but the performance is the same because it turns out most of what our service did was waiting’.

Lua with LuaJIT has pretty good performance. With that said, I spent today writing in C++, so I do agree with the overall sentiment.

Only semi-relevant, but there's also the fact that lower level languages can auto-optimize more deeply -- but that's also more my intuition (would love to get learnt if I'm wrong).

For example, I'd expect that Rust (or rustc I guess) can auto-vectorize more than Node/Deno/etc.

"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.

Reminds me of using Ruby ten years ago and having to contend with folks who wanted to default to using the string literal style over another because it was known to be more performant at scale. That awkward stuff surfaces earlier with some languages than with others.

Of course that's why we're discussing it. I'm referring to stronger interop like how you can embed ASM in C, and therefore CPP.

Like a JS/TS that can have compiled blocks specified in the same language, preferably inline? I'm reaching here.

Common Lisp (SBCL)?

I guess if folks write JS with the idea that optimisations are needed in mind, then the chances of premature optimisations may go up along with those of the required ones

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?

Don't forget Scheme (Gambit, Chez, Racket).

That's true, though I'd argue these are not as dynamic.

I really don't think the problem is JavaScript in all these cases. I've seen codebases using webpack where the JS was being run through babel twice in a row, because webpack is a complicated nuisance and nobody on the team had gotten around to fixing it. You can't blame that on V8 or node being slow.

Javascript should introduce integers and structs and it will have 10-100x the performance it has today without spending another $100 billion on VM optimization.

But why use JavaScript at all if you can just compile it all to WebAssembly?

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.

Ahead of Time, perhaps. (Of course the benefit of AOT is that you can take all the time in the world and only slow down the developer cycle without impacting users. In theory you can always build a slower AOT compiler with more optimizations, even/especially for higher level languages like JS. You can almost always trade off more build time and built executable size for more runtime optimizations. High level languages can almost always use Profiler Guided Optimization to do most things low level languages use low level data type optimization paths for.)

A benefit to a good JIT, though, is that you can converge to such optimizations over time based on practical usage information. You trade off less optimized startup paths for Profiler Guided Optimization on the live running application, in real time based on real data structures.

JS has some incredible JITs very well optimized for browser tab life-cycles. They can eventually optimize things at a low level far further than you might expect. The eventually of a JIT is of course the rough trade-off, but this also is well optimized for a lot of the browser tab life-cycle: you generally have an interesting balance of short-lived tabs where performance isn't critical and download size is worth minimizing, versus tabs that are short-lived but you return to often and can cache compiled output so each new visit is slightly faster than the last, versus a few long-lived tabs where performance matters and they generally have plenty of time to run and optimize.

This is why Node/Deno/et al excel in long-running server applications/services (including `--watch` modes) and "one-off"/"single run" build tools can be a bit of a worst case, they may not give the JIT enough time or warning to fully optimize things, especially when they start with no previous compilation cache every time. (The article points out that this is something you can turn on now in Node.)

It's also fascinating how many developers got so burnt on IE11- compatibility issues and feel a need to use Babel as a comfort blanket still. Babel does so very little now with reasonable, up-to-date Browserlist defaults (but still takes a lot of time to do so very little), but the number of developers unwilling to drop Babel from their build pipelines is still to me so surprisingly high. Babel was a great tool for what it did in the "IE11 is still an allowed browser" era, but you most probably don't really need it today.

I prefer using Python with pybind11. It makes writing new modules or embedding the whole interpreter quite simple.

Because I have better use of my time than waiting for 2 minute compile times on every little change. And believe it or not - I actually like JS with object destructuring, Promises and async/await.