It's maybe 90% right in general, but it's 10% right (90% wrong) for the workload of language processors in particular. Lots of tiny objects are terrible worklo

It's maybe 90% right in general, but it's 10% right (90% wrong) for the workload of language processors in particular. Lots of tiny objects are terrible workloads for JavaScript and Python. Related comments: https://news.ycombinator.com/item?id=35045520 https://news.ycombinator.com/item?id=35045520 Direct comparison I did between Python and C++ semantics - Oil's Parser is 160x to 200x Faster Than It Was 2 Years Ago - https://www.oilshell.org/blog/2020/01/parser-benchmarks.html https://www.oilshell.org/blog/2020/01/parser-benchmarks.html This is the same realistic program in both Python and C++ -- no amount of "optimizing Python" is going to get you C++ speed. --- FWIW I agree with you about the debates -- many people can't seem to hold 2 ideas in their head at once. Like that C++ unordered_map is atrociously slow, but C++ is a great language for writing hash tables. And that Python was faster than Go for hash table based workloads when Go first came out, but also Python is slow for AST workloads. Performance is extremely multi-dimensional, and nuanced, but especially with programming languages people often want to summarize/compress that info in inaccurate ways.