For clarity: Perl6 does suffer from the same implementation problems as Java and always will. Nevertheless ...
In my post I didn't use the word "always" because who knows what will happen? Maybe in 5 years Rakudo will be abandoned and the standard Perl6 implementation will be quite different. But I've seen nothing to suggest that, looking from the outside.
AFAICS, Perl and Perl6 will always have orthogonal use cases. It's only the Perl6 name which will damage Perl's usage and that is a real shame.
Update Oct 2019: I'm pleased to say that there is finally a new name for this language (Raku) which we can all hope will go some way to mitigating the damage already done to Perl and ensure that no more is done in future.
| [reply] |
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?
| [reply] |
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] |
| [reply] |
same implementation problems as Java and always will.
Interesting, why?
| [reply] |
