TL;DR Imo, for at least the next year, the P6 project needs to encourage contribution by folk who enjoy creating an entire system and discourage use by folk who just want to get stuff done.
----
I've loosely followed P6 since 2000; daily read the log of the central hub of P6 activity -- the IRC channel #perl6 -- for the last 3 years; and summarized it daily for the last 2 years.
I am concerned about folk getting the wrong impression about Rakudo's readiness for general use by mainstream programmers that just want to get stuff done.
I started using the following disclaimer a year ago and I think it still sets expectations appropriately:
Perl 6 is not remotely as usable and useful as Perl 5; it has dozens of users, not millions; it is 100-1000x slower than Perl 5 for a lot of stuff; the P6 documentation is immature and incomplete; the spec has not reached 6.0.0; the Rakudo compiler has not fully implemented what's already in the spec; most of the concurrency and parallel implementation has only just begun; P6 can not currently use CPAN modules; Perl 6 has syntax and semantics that are not backwards compatible with Perl 5; Perl 6 culture is -Ofun which some think is incompatible with getting things done; some folk think that Perl 6 code looks like line noise... In summary, there are infinitely many things wrong with P6.
----
> From what I read ... rakudo is very close to spec completeness ... implementing last bits of spec and improving the speed
Ignore implementation (Rakudo) for a moment.
The spec isn't complete.
There's very recent talk of producing "a list of big ticket items remaining" for "hitting 6.0" and "a tri-color marking of the spec" showing "Implemented in Rakudo, not implemented but we agree we really should for 6.0, deferred to 6.*".
I think only some one far detached from reality would expect, a Perl 5 like ecosystem ready on the day of Perl 6.0.0 release. And most people don't need many Perl 6 esoteric features either. So I guess your "a list of big ticket items remaining" hopefully won't be "a big list of ticket items remaining".
Besides I was of an opinion even after the 6.0.0 release the spec won't be complete. Spec will never be complete. Spec is a backwards compatible changing piece of document which the implementation tries to catch up with. The stable releases of the implementation are production releases.
Lastly you could just say. Esoteric features a, b, c, d are left for next 6.* releases. While release a 6.0.0 release is cut after with whatever you decide from that list earlier. The world is in no hurry to use the esoteric features anyway.
Either way, I wish you guys all the very best. And hope to soon see a closure soon on this.
> I think only some one far detached from reality would expect, a Perl 5 like ecosystem ready on the day of Perl 6.0.0 release.
I think it's still plausible that someone (it'll have to be one or more serious P5 guts hackers) will soon start implementing something like diakopter's plan for P5+XS interop. (That's the plan for having P6 code calling P5 code and back again, including XS modules on CPAN.) If that works out well, a 6.0 release could be viewed as including all of the P5 ecosystem or, conversely, as an experimental part of P5.
But perhaps I'm far detached from reality.
I certainly wouldn't expect the project to wait for such interop. If 6.0 has to ship without support for P5+XS modules, so be it.
> So I guess your "a list of big ticket items remaining" hopefully won't be "a big list of ticket items remaining".
> Besides I was of an opinion even after the 6.0.0 release the spec won't be complete.
It sounds like the plan is to mark particular bits (paragraphs?) as either 6.0 or post 6.0 and associated spectests will determine whether or not Rakudo is compliant.
> Esoteric features a, b, c, d are left for next 6.* releases.
I don't know about the esoteric aspect being the decider, but yes, I'm assuming the basic idea will be to defer as much as is reasonable.
> Either way, I wish you guys all the very best. And hope to soon see a closure soon on this.
{ "this" }
Maybe not what you're after?
Seriously, while I hope for a 6.0 spec this year I think there's about zero chance of a 6.0 Rakudo this year. And unless a few dozen more contributors turn up maybe not in 2015 either.
----
I've loosely followed P6 since 2000; daily read the log of the central hub of P6 activity -- the IRC channel #perl6 -- for the last 3 years; and summarized it daily for the last 2 years.
I am concerned about folk getting the wrong impression about Rakudo's readiness for general use by mainstream programmers that just want to get stuff done.
I started using the following disclaimer a year ago and I think it still sets expectations appropriately:
Perl 6 is not remotely as usable and useful as Perl 5; it has dozens of users, not millions; it is 100-1000x slower than Perl 5 for a lot of stuff; the P6 documentation is immature and incomplete; the spec has not reached 6.0.0; the Rakudo compiler has not fully implemented what's already in the spec; most of the concurrency and parallel implementation has only just begun; P6 can not currently use CPAN modules; Perl 6 has syntax and semantics that are not backwards compatible with Perl 5; Perl 6 culture is -Ofun which some think is incompatible with getting things done; some folk think that Perl 6 code looks like line noise... In summary, there are infinitely many things wrong with P6.
----
> From what I read ... rakudo is very close to spec completeness ... implementing last bits of spec and improving the speed
Ignore implementation (Rakudo) for a moment.
The spec isn't complete.
There's very recent talk of producing "a list of big ticket items remaining" for "hitting 6.0" and "a tri-color marking of the spec" showing "Implemented in Rakudo, not implemented but we agree we really should for 6.0, deferred to 6.*".