[Perl 6] A poll about VMs.

poll_perl6_vms

Hey!

This is a poll about VMs for Perl 6. It would be awesome if you fill it,
just write a comment with your answers or fork it and edit.

I need it because I work on a huge summary (including, among the others, statistics, tests)
of VMs and Perl 6 itself.

Thank you very much in advance!
sergot


THE POLL


Your knowledge

1. Which VMs for Perl 6 do you know?

2. What are their defects (e.g. too long execution) and
how hard is it to fix them (how long would it take, how many people can do this etc.)?

3. What is the worst and the best thing about those VMs?


Your choice

4. Which VM do you use most often?

5. Why do you use this VM? (please write all known advantages and disadvantages)

6. Do you know any bugs in this VM?

7. How do you think, which VM would have the greatest future? Which one would be "the chosen one"?


Others

8. You can write some useful information about VMs, links etc.


Do not hesitate to criticize this poll, suggest new questions, correct any mistakes and so on.
Thank you! :)

PS.
If you want to contact me, you can find me on:
#perl (irc.perl.org)
#perl6 (irc.freenode.net)

my nickname is "sergot".

https://gist.github.com/slunski/9970983

http://irclog.perlgeek.de/perl6/2014-04-04#i_8540716

I am limiting my answer to rakudo because I don't know the other implementations
Than I describe the benefit dynamically downloading moar bytecodes bundled in archive (TBD)
which would be more or less like jar files ; I don't think it is specced.

1. -Parrot : Soon, parrot will be history. It was useful when there was no alternative.
   -JVM is nice for interoperability with the Java world but the start up time makes it inappropriate for Perl as
   a scripting language where it can be called from a shell for minute tasks
   -Moar : Except for this interoperability, Moar is the appropriate VM. It may eventually interact
   with Java bytecode as well using some of the machinery of the JVM backend. Knowing that Parrot is
   history, the last remark make the question moot. The only VM would Moar subsuming the JVM one.
   -V8: But the greatest opportunity would be a modified V8 backend that would know about moar bytecode.
   Such a modified V8 in web browsers that would mean the end of javascript as the sole language.
   That would solve the Perl visibility because everything web would be Perl seen as a meta language
   to implement any other for writing client web code.

If I understand correctly, moar bytecode is portable. This mean we can distribute small binary rakudos
that download moar archives when needed from CPAN servers. A moar bytecode is for a compilation
unit. A moar archive, tentatively using .armor as a suffix, would bundle many moar bytecodes possibly
from many CPAN modules. Bytecodes in archives would be ordered from the more used to the less so
that execution can begin before the whole loading.
So a module that is dependant on many others can bundle everything in a single .armor
Usually, to save memory, except when explicitely requested, rakudo-moar will load only the latest version
of a module. So it will not use every bytecodes in an armor because when he locally got a more recent version of a bytecode. But using a wholesale armor could be a failsafe backup solution in case of problem.

1. Parrot, JVM, MoarVM, also .NET (CLR) which niecza is running on.
2. MoarVM is a magical wonderland and has no bad sides :D
   JVM has a slow startup time, which is unbearable in development.
   Parrot is basically inferior to MoarVM in every possible way these days, and I don't ever expect it to get better; Parrot development is almost nonexistent.
3. Best things:
   Parrot: module ecosystem support
   JVM: speed, once JIT kicks in; very nice parallel capabilities
   MoarVM: speed; amazing development progress
   Worst things:
   Parrot: almost a complete lack of non-blocking IO, lack of threading
   JVM: glacially slow startup/compilation times
   MoarVM: um, no idea. As I said, it's a wonderland full of ponies and rainbows
4. MoarVM
5. Rapid startup, compilation and runtime makes Perl6 development very, very pleasant
6. I've encountered some (with macros), maybe they are fixed already. There are no other bugs that I've encountered that don't exist on other VMs too
7. MoarVM ftw