> Faster than Perl5 with Moose, but slower than similar languages with similar features. But there are not many with this impressive feature set.

Which languages with "similar features" are you comparing to Perl 6 here, and (given the second sentence) are the feature sets really similar?

With all these different implementations how hard is it to access C libraries and/or make modules that use C?

Not very difficult, see http://doc.perl6.org/language/nativecall

As simple as writing a Perl6 signature for your C function. A proper solution for deploying your own libraries has yet to arrive (you can look up library names at runtime and compile code via the module manager, but imo it's still rather ad-hoc).

Not very (hard): https://github.com/jnthn/zavolaj

Shame it's slower than existing work. We know pretty well how to optimise dynamic languages these days.

We != the perl community.

They still have no idea how a fast dynamic language should be designed. To their advantage python does neither. Ruby does know, but doesn't get along with to well. Only PHP got their act together with 7.0.

You overlook the addendum in the parent post.

I don't think so - it's still 'slower than similar languages with similar features', so not sure what difference it makes that there aren't many languages to compare against, if when we do compare it's still slower.

I'd be interested to see what features there are that make the system slower in general, even when they aren't being used. I did a lot of work in my PhD on making odd features not affect the performance of Ruby code when they aren't being used.

Do you know what they are?

    > I'd be interested to see what features there are that
    > make the system slower in general, even when they
    > aren't being used. I did a lot of work in my PhD on
    > making odd features not affect the performance of
    > Ruby code when they aren't being used.

I suspect you would be warmly welcomed, and meet many interesting people, in the Perl6 IRC channel, especially if you lead to a link to your PhD.

My main guesses:

* multiple dispatch * the meta-object protocol

And the thing is, these features are being used all the time, because the core language is built out of them. If you want to see how a language which is not built on these things runs (on the same vm implementation, I might add), I suggest you try nqp :-).

https://github.com/nqp/nqp

Don't forget about the grammar engine - the parsing speed is only in the hundreds as measured in lines of code/s, which is a concern for script startup.

I've come up with rather 'creative' workarounds[1] until a more proper solution arrives...

[1] https://github.com/cygx/6make/blob/master/6make

He does call it a "compiler" in the video. Maybe that's temporary while it's still unoptimized, or a change in direction?

Perl5 historically has compiled to bytecode and then interpreted the bytecode. I imagine that's what's going on here.

If you click the green Start... button at this page: https://kiwiirc.com/client/irc.freenode.net/perl6?nick=chris... (change the nick if you want) you'll join the real time chat room (IRC) dedicated to developing Perl 6. (Here's today's log if you want to look first: http://irclog.perlgeek.de/perl6/today

You can type 'hi', ask folk to read your above comment (https://news.ycombinator.com/item?id=10565204 ), and then seen what unfolds when you chat for a few minutes. :)

Not directly, sadly. I can make an educated guess though, since Perl 5 has since adopted many of the features thought up for Perl 6. Particularly try looking at its OO features, in regards to roles, parametrized roles, reflection and automated attribute/constructor creation. I can't say with confidence, but i suspect the number of languages having all those features is very low, if existent, and the number of languages with some of these features is also low.

Do note that you will have to look closely and follow references to make sure you have a full picture of understanding, since at first glance many of them seem simple, but turn out to offer considerable depth.

http://doc.perl6.org/language/objects

I'm not sure if Perl 5 has adopted these features, but these features have been implemented in Perl 5 via modules [0], which is excellent - but sadly, this is vastly different than being in core, or even having the modules in core. I don't even think you can set default attributes in Perl 5 methods. You still have to pass around the object, shift it off - a whole lot of boilerplate. Something as simple as that has been proposed, but it's not been in production for Perl 5. (without Moose and friends, of course)

Really, there hasn't been a terrible amount of new features in Perl 5 - and certainly not a new model for OO. Moose is great! And the constant release of CPAN modules is also wonderful, but the core of Perl 5 is full of dragons, which makes backporting features from Perl 6 hard to do in core - and perhaps a good argument can be made against doing that. Example: Moose is a very successful project, but thee given/when statement in the core of Perl was a failure.

[0] http://moose.iinteractive.com/en/

I could write a lot to explain it, but at the end of the day, unless you can accept the following it is not worth the effort.

CPAN is the language, perl is just the VM.

We do, but it's a hell lot of work, especially for something much more complicated than Javascript.

Do you have a link to benchmarks you'd recommend that show it being faster than Perl5 with Moose?

http://perlformance.net/charts/ is the usual pointer, but it has no easy to show comparison.

There's also the perl6 specific benchmark https://github.com/japhb/perl6-bench but I have no idea where they post their results to. It used to be a gist or IRC.

I know about startup time: https://gist.github.com/mj41/6761c021135ae1cb17f9

BTW: Not Moose related - loop with native int: https://gist.github.com/mj41/20c70566564283151714

And they really haven't done any optimizations for speed yet. Larry mentions that in his talk.

Excuse me? The whole 2 last years was mostly spent on MoarVM and it's optimizations. That's why we are having this release in the first place.

Is JIT going to be on the horizon (sorry didn't watch the full video)?

It's already there on x64.

Note that to fully take advantage of it, the optimization layer above it that does type specialization also needs work (eg some optimizations were lost during the 'Great List Refactor', a semantic change that was set as one of the blockers for the 6.0 release).