I usually don't program in Perl, but occasionally use it instead of sed.
Compare, Perl 5 vs. Perl 6:
$ time yes | head -n1000000 | perl -pe 's/y/n/' >/dev/null
real 0m0.945s
user 0m0.944s
sys 0m0.016s
$ time yes | head -n1000000 | perl6 -pe 's/y/n/' >/dev/null
real 2m49.881s
user 2m44.892s
sys 0m2.184s
Spending several minutes to do what can be done in under 1 second is just unacceptable.
It's nice to dream up a language with the perfect semantics; in reality, all programming languages make compromises because they are limited by current compiler technology. Ruby is on one extreme end of the spectrum, making little compromises on beauty, but we all know how slow it is.
Go is on the other end of the spectrum; they have tuned their syntax to be fast to parse, and have stuck to implementing existing compiler technology. If your semantics are very far removed from how computers work, you need a very advanced compiler like GHC.
It sounds like Perl6 is somewhat centrist in its approach, and has innovated quite a bit; I think it will be possible to almost match Perl5's speed with reasonable effort. The interpreter might do well on small examples, but the VM will dominate in very large ones. Many compilers are tiered in that they use an interpreter for cold code, and spend the effort to generate code and JIT hot code.
The “cutting edge” of technology or craft is the newest / greatest stuff, pushing the field forward in new unexplored directions, by analogy to the cutting edge of a plow or a knife which slices through some uncut material or unbroken ground. I believe the metaphorical use of the term dates from the middle of the 20th century.
The “bleeding edge” is a more recent term for the same idea, emphasizing that being at the cutting edge might involve danger to yourself.
Yes, I haven't tried lately, but for my own small text manipulation program, Perl 6 was still more than 100 times slower than Perl 5 the last time I tried. Probably because of some JIT delaying the startup time. But since my use is calling small programs, it was a no go for me; and after one year it had not improved a bit.
wow, that is insane. You picked an awesome example.
We're only talking about on the order of a million bytes in your example, so 2 minutes to process on the order of 1 megabyte with a regex is just insane. If you applied it to 1 gigabyte of files that would be an even 2 days vs Perl 5 @ 16 minutes.[1] Sixteen minutes isn't enough to rewrite it in C, so Perl 5 is "fast enough". You can go get a coffee or think about the next thing you want to do with the data, or write the next part of your processing. But two days is prohibitive: it breaks your workflow.
It might help to point out that the core team only froze the spec during Christmas last year or year before and have therefore just started on performance in a way. If you check the perl6 weekly site you'll see significant progress on a weekly basis (ex: Lists sped up by 1500%).
So, a fairly simple change to this will bring down the time to a few ms (86 ms on my computer)
time yes | head -n1000000 | perl6 -e 'for $*IN.readchars { .subst("y", "n").print }’
Its slightly more complicated because I’m having it read the input in a chunk instead of on a per-line basis and I’m using subst on a literal instead of a regex.
I usually don't program in Perl, but occasionally use it instead of sed.
Compare, Perl 5 vs. Perl 6:
Spending several minutes to do what can be done in under 1 second is just unacceptable.