[microwavecamera]

All of the popular interpreted languages we use now were dog slow when they originally came out and we still had to deal with many the quirks of low level languages back then but here we are. If you don't like it just don't use it.

[acdha]

This really depends on the task in question and which languages you were comparing it to. Back in the day it was fairly common to have Perl, PHP, Python, etc. outperform languages like C in cases where the task complexity meant that the C programmer had been so busy debugging that they never got around to implementing a better algorithm which required more complex code, or it turned out that the C code behind the Perl regex engine, Python list/dict, etc. already had those optimizations. Java and C++ were compiled but back then the implementations were far less mature and it was easy to find cases where they underperformed in cases which should have been easy on paper. Not having a package manager really favored languages with one or a strong standard library since the alternative was often someone doing a quick naive implementation and never getting around to significant optimizations. The other thing to remember is that in the pre-SSD era it was much easier to be I/O-bound, masking most of the differences.

[b2gills]

Someone once posted Perl6 and C/C++ code to #perl6 on freenode.net

According to them, Perl6 was faster.

(The Perl6 code was also a lot shorter, and I could argue it was easier to understand.)

---

My guess is that the reason was that the C/C++ code had to scan for null terminators often, and copy strings around. (Or perhaps more precisely the stdlib had to do that.)

MoarVM doesn't use null terminated strings, and it treats strings as immutable objects. If you do something like create a substring, it creates a substring object that points into the original string. So rather than copying a bunch of data it basically just creates a pointer.

(Strings are technically immutable in Perl6, it is easy to assume otherwise though.)