/gist:6096722

## gistfile1.txt
Carlos,

Your opinion does matter, and your question/objection is a good one.

MoarVM's future is definitely unclear if you're unfamiliar with the
current status of Parrot (especially compared to MoarVM).  One thing
contributing to this confusion is the fact MoarVM was only recently
revealed, when it has in fact been under *intense* development for more
than a year prior to that.  Here are some facts about MoarVM and
Parrot's status w.r.t. Rakudo that should promote some of this tribal
knowledge to general awareness.

  1. First, MoarVM has many more active developers than Parrot.  The
  last remaining active Parrot developer has publicly said he wants to
  take Parrot in a new direction (notably, one that doesn't support
  Rakudo Perl 6).  MoarVM has at least 4 extremely active contributors,
  and another several active contributors.
  2. Second, Parrot has technical limitations preventing further
  expansion of Rakudo Perl 6's capabilities using the Parrot backend,
  which preclude it from being a good platform on which to prototype
  Rakudo's libperl interop.
    a. Parrot's concurrency features (in their current form) are
    devastatingly unusable by Rakudo:
      1) Its barriers (to intercept accessor and mutator PMC opcalls and
      redirect those calls to the thread that allocated the PMC) are
      only on the PMC v-tables, and not on the 6model v-tables, which
      are what Rakudo uses, so that mechanism would need redesigned in
      light of 6model, of which the author of Parrot's threads clearly
      wasn't aware.
      2) Currently, only parrot's main (first/original) thread can spawn
      new threads, and its child threads cannot interact with each other
      via shared objects, so objects returned to the main thread from
      child threads should not be accessible from another child thread
      [... but there is no built-in protection against this].  Claims
      this is easy to fix are less than veracious.
      3) Since only the allocating thread can access or mutate its
      shared objects, no object can be accessed by more than one thread
      at once, so there can be no such thing as lock-free shared
      objects, since every object is thread-safe, due to requiring a
      lock for all operations, including reading!  However, it is even
      worse than this: all objects created by the main thread *share the
      same lock*, since only one of them can be accessed at once.  This
      manifests practically as a limitation that if you want to have
      multiple child threads utilize shared objects, the only work that
      can be done concurrently is work that doesn't access any shared
      objects.  This relegates Parrot threads to the same effectiveness
      domain as JavaScript's web-workers.
      4) Parrot's garbage collector has no way of knowing when a given
      object can be freed, because it does not know whether or not it
      has passed that pointer to another thread (deeply
      accessible/nested), if there are no more references to that
      pointer in its own thread.  Parrot's thread design attempts to
      mitigate this by keeping track of which objects it *explicitly*
      sends to other threads... but it fails to keep track of any
      objects reachable from *that* object (at the time of passing it),
      if that pointer is a collection/container object with links of its
      own, but then the link to the other object was broken, but is
      still held as a reference by another object, in that other thread.
       This effectively means that no memory can ever be safely freed by
      Parrot, and thus it has no garbage collector.  How someone thought
      one could invent a safe concurrent garbage collector with only a
      few hours work is pretty much unfathomable, especially when one is
      discovering an entirely unheard-of method of doing something that
      normally takes thousands of hours of work by professionals with
      decades of related experience, instead of being designed for a
      junior undergrad semester project.
    b. Parrot has no asynchronous I/O, and no one has any plans to
    incorporate it, contrary to the Parrot Design Documents, which are
    written as if it already exists.  MoarVM has resources committed to
    furnishing this by this year.
    c. Parrot has no knowledge of anything having to do with signals
    (and again, no one has claimed they are available, willing, or able
    to provide them); MoarVM will have them soon.
    d. Parrot has no interaction with (or control of streams of) child
    processes, except that it can read stdout from a child process (and
    again, no one has claimed they are available, willing, or able to
    provide anything beyond this).  MoarVM has somewhat more control
    (via APR currently), but when APR is replaced (probably by some
    variant of libuv), we'll enable capabilities equivalent to Perl 5's
    child process extensions.
    e. Parrot has no atomic operations; MoarVM does.
    f. Parrot's potential for optimizing Perl 6 regexes is very limited
    due to its reliance on libicu and its limited API.  MoarVM already
    has its own implementation of the Unicode Character Database, and so
    doesn't have this limitation.
    g. Parrot has no JIT (and again, no one has claimed they are
    available, willing, or able to work on this).  MoarVM plans one
    within a year (and again, more than several qualified resources are
    lined up to do it).
    h. Parrot takes ages to build compared to MoarVM (and not because it
    provides more features), which constrains its developer productivity
    dramatically.
  3. Even parrot devs (3 recently core/chief ones, afaik) have said
  MoarVM can be viewed as a continuation of Parrot's ideals and goals...
  implying they view Parrot's ability to further those goals has reached
  its end [recently, if not a long time ago].
  4. At this moment, MoarVM passes over 90% of NQP's test suite (NQP
  defines the opcode set for Rakudo backends and a Perl-6 like language
  with many of its features). The JVM backend accomplished this only a
  few short weeks ago, and now passes over 99% of the Perl 6 test suite
  that Rakudo on Parrot passes, which bodes well for MoarVM's ability to
  catch up quickly.

As stated in the grant application, much of the work is already
applicable to the same features on the JVM backend; in fact I considered
proposing funding that instead of using the MoarVM backend, but I chose
MoarVM when it became clear Rakudo would likely be caught up in time.

Regarding the amount of money, it is about 3/4 of the remaining
uncommitted funds and 1/2 of the remaining total funds.  Much (or all?)
of the $100k portion of the Hague Grant was for fund-raising activities,
and that still remains.  Do you have any ideas for how to spend that,
other than hiring someone full-time for a year to fund-raise (which was
previously proposed and rejected)?  [I can't think of anything right
now, but I can think of plenty to do once Perl 6 has a marketable
product.]

I appreciate your question; I hope this answer has helped clear up some
of the cognitive dissonance.
	Carlos,

	Your opinion does matter, and your question/objection is a good one.

	MoarVM's future is definitely unclear if you're unfamiliar with the
	current status of Parrot (especially compared to MoarVM). One thing
	contributing to this confusion is the fact MoarVM was only recently
	revealed, when it has in fact been under intense development for more
	than a year prior to that. Here are some facts about MoarVM and
	Parrot's status w.r.t. Rakudo that should promote some of this tribal
	knowledge to general awareness.

	1. First, MoarVM has many more active developers than Parrot. The
	last remaining active Parrot developer has publicly said he wants to
	take Parrot in a new direction (notably, one that doesn't support
	Rakudo Perl 6). MoarVM has at least 4 extremely active contributors,
	and another several active contributors.
	2. Second, Parrot has technical limitations preventing further
	expansion of Rakudo Perl 6's capabilities using the Parrot backend,
	which preclude it from being a good platform on which to prototype
	Rakudo's libperl interop.
	a. Parrot's concurrency features (in their current form) are
	devastatingly unusable by Rakudo:
	1) Its barriers (to intercept accessor and mutator PMC opcalls and
	redirect those calls to the thread that allocated the PMC) are
	only on the PMC v-tables, and not on the 6model v-tables, which
	are what Rakudo uses, so that mechanism would need redesigned in
	light of 6model, of which the author of Parrot's threads clearly
	wasn't aware.
	2) Currently, only parrot's main (first/original) thread can spawn
	new threads, and its child threads cannot interact with each other
	via shared objects, so objects returned to the main thread from
	child threads should not be accessible from another child thread
	[... but there is no built-in protection against this]. Claims
	this is easy to fix are less than veracious.
	3) Since only the allocating thread can access or mutate its
	shared objects, no object can be accessed by more than one thread
	at once, so there can be no such thing as lock-free shared
	objects, since every object is thread-safe, due to requiring a
	lock for all operations, including reading! However, it is even
	worse than this: all objects created by the main thread *share the
	same lock*, since only one of them can be accessed at once. This
	manifests practically as a limitation that if you want to have
	multiple child threads utilize shared objects, the only work that
	can be done concurrently is work that doesn't access any shared
	objects. This relegates Parrot threads to the same effectiveness
	domain as JavaScript's web-workers.
	4) Parrot's garbage collector has no way of knowing when a given
	object can be freed, because it does not know whether or not it
	has passed that pointer to another thread (deeply
	accessible/nested), if there are no more references to that
	pointer in its own thread. Parrot's thread design attempts to
	mitigate this by keeping track of which objects it explicitly
	sends to other threads... but it fails to keep track of any
	objects reachable from that object (at the time of passing it),
	if that pointer is a collection/container object with links of its
	own, but then the link to the other object was broken, but is
	still held as a reference by another object, in that other thread.
	This effectively means that no memory can ever be safely freed by
	Parrot, and thus it has no garbage collector. How someone thought
	one could invent a safe concurrent garbage collector with only a
	few hours work is pretty much unfathomable, especially when one is
	discovering an entirely unheard-of method of doing something that
	normally takes thousands of hours of work by professionals with
	decades of related experience, instead of being designed for a
	junior undergrad semester project.
	b. Parrot has no asynchronous I/O, and no one has any plans to
	incorporate it, contrary to the Parrot Design Documents, which are
	written as if it already exists. MoarVM has resources committed to
	furnishing this by this year.
	c. Parrot has no knowledge of anything having to do with signals
	(and again, no one has claimed they are available, willing, or able
	to provide them); MoarVM will have them soon.
	d. Parrot has no interaction with (or control of streams of) child
	processes, except that it can read stdout from a child process (and
	again, no one has claimed they are available, willing, or able to
	provide anything beyond this). MoarVM has somewhat more control
	(via APR currently), but when APR is replaced (probably by some
	variant of libuv), we'll enable capabilities equivalent to Perl 5's
	child process extensions.
	e. Parrot has no atomic operations; MoarVM does.
	f. Parrot's potential for optimizing Perl 6 regexes is very limited
	due to its reliance on libicu and its limited API. MoarVM already
	has its own implementation of the Unicode Character Database, and so
	doesn't have this limitation.
	g. Parrot has no JIT (and again, no one has claimed they are
	available, willing, or able to work on this). MoarVM plans one
	within a year (and again, more than several qualified resources are
	lined up to do it).
	h. Parrot takes ages to build compared to MoarVM (and not because it
	provides more features), which constrains its developer productivity
	dramatically.
	3. Even parrot devs (3 recently core/chief ones, afaik) have said
	MoarVM can be viewed as a continuation of Parrot's ideals and goals...
	implying they view Parrot's ability to further those goals has reached
	its end [recently, if not a long time ago].
	4. At this moment, MoarVM passes over 90% of NQP's test suite (NQP
	defines the opcode set for Rakudo backends and a Perl-6 like language
	with many of its features). The JVM backend accomplished this only a
	few short weeks ago, and now passes over 99% of the Perl 6 test suite
	that Rakudo on Parrot passes, which bodes well for MoarVM's ability to
	catch up quickly.

	As stated in the grant application, much of the work is already
	applicable to the same features on the JVM backend; in fact I considered
	proposing funding that instead of using the MoarVM backend, but I chose
	MoarVM when it became clear Rakudo would likely be caught up in time.

	Regarding the amount of money, it is about 3/4 of the remaining
	uncommitted funds and 1/2 of the remaining total funds. Much (or all?)
	of the $100k portion of the Hague Grant was for fund-raising activities,
	and that still remains. Do you have any ideas for how to spend that,
	other than hiring someone full-time for a year to fund-raise (which was
	previously proposed and rejected)? [I can't think of anything right
	now, but I can think of plenty to do once Perl 6 has a marketable
	product.]

	I appreciate your question; I hope this answer has helped clear up some
	of the cognitive dissonance.