4 ms·
It mostly depends on the application. If you're doing complex transforms over hundreds of GBs of data- yeah, use a workhorse for that. But the vast majority of
by causal 2y ago
It mostly depends on the application. If you're doing complex transforms over hundreds of GBs of data- yeah, use a workhorse for that.
But the vast majority of slow JS I've encountered was slow because of an insane dependency tree or wildly inefficient call stacks. Faster languages cannot fix polynomial or above complexity issues.
- chubot 2y agoYeah but the application we're talking about here is JavaScript tools, or more generally "language processors" / AST-based workloads These are very different than your average JavaScript program And that's exactly where it starts to be the case that JavaScript semantics are the issue Take it from Lars Bak and Emery Berger (based on their actions, not just opinions): https://lobste.rs/s/ytjc8x/why_i_m_skeptical_rewriting_javascript#c_9yf3tq https://lobste.rs/s/ytjc8x/why_i_m_skeptical_rewriting_javas... :)
- munificent 2y ago> If you're doing complex transforms over hundreds of GBs of data- It's not always about giant datasets. Latency matters too for software that is run frequently by users. I maintain a code formatter. In a typical invocation, it's processing only a few hundred kilobytes of input data. But it is invoked every time a user hits control-S, thousands of times a day. If I make it a few hundred milliseconds slower, it materially impacts their flow and productivity. > Faster languages cannot fix polynomial or above complexity issues. This is true. But once you have fixed all of your algorithmic issues, if your language is slow, you're completely stuck at that point. You have hit a performance ceiling. Personally, I would rather work in a language where that ceiling is higher than it is in JavaScript.