Re^7: Think Perl 6 (new book)

Thank you. So I'm now thinking your overall opinion might be stated as something like "It seems that Perl 6, or at least the Rakudo Perl 6 compiler, will almost certainly always suffer from the same implementation problems as Java, or at least javac, due to its architecture, for many of Perl 5's most popular use cases."

Are these problems you see specific to particular VMs like the JVM? Or do you see the same sorts of problems applying even to, say, LuaJIT and its VM, for much the same reasons?

If LuaJIT's VM is OK, what are the main things about it that makes the LuaJIT project a fundamentally different and potentially acceptable architectural approach, in your view, for the use cases you focus on?

If you think that some VMs, in some scenarios relevant to you, can be a good thing, what are the main things that lead you to think that MoarVM misses the mark?

Comment on Re^7: Think Perl 6 (new book)

Replies are listed 'Best First'.
Bytecode VMs are not a panacea Re^8: Think Perl 6 (new book) by hippo (Bishop) on May 19, 2017 at 16:42 UTC
If you think that some VMs, in some scenarios relevant to you, can be a good thing I can't immediately think of any scenario relevant to me where a VM would be a good thing, no. I do however see other situations where they might be: phones, embedded, applets, etc. Hence my comment about the orthogonal use cases. I have barely used Lua so am not qualified to comment on the particulars there. Conversely, I have battled frequently against the JVM and will be a very happy camper if I never have to deal with it or its like ever again. The problems with it which are so bad that it is unsuitable for pretty much any of my types of work include: It is glacially slow It requires constant care and attention in both invocation and running It does not recover gracefully It is an unbelievable resource hog It isn't compatible with other versions of itself (despite write-once-run-anywhere being one of the principles of Java as a language)* It isn't even compatible with other versions of itself from the same vendor* It doesn't integrate well with non-java libs and utilities* While those I've marked with an asterisk are quite possibly "features" of the JVM only, the others do appear to be equally applicable to other VMs. Those areas I mentioned where VMs might be a boon (phones, embedded, applets) are no doubt ripe for Perl6 when it hits maturity. The rest, not so much. Those of us who work elsewhere would very much like to keep on using Perl instead and not have to explain constantly why Perl6 isn't an upgrade.	[reply]
Re: Bytecode VMs are not a panacea by KurtZ (Friar) on May 19, 2017 at 16:58 UTC
So does Scala suffer from the same problems because of the JVM?	[reply]
Re^8: Think Perl 6 (new book) by Anonymous Monk on May 19, 2017 at 21:00 UTC
what are the main things that lead you to think that MoarVM misses the mark? It shows no signs of learning anything from Javascript VMs. And Lua is a very different language from Perl6.	[reply]


Clear questions and runnable code get the best and fastest answer
	PerlMonks