Re: Are you using Perl 6 in production?

No, currently i'm not using Perl 6. Beside not having time (and any need to) re-write half of my source code and the non-availibility of ActiveState tools for P6, i'm not really happy with the landscape surrounding P6.

For example, more or less forcing developers to use Github is just stupid. For one, P6 will run into exactly the same Problems as node.js (one developer depublishes something and the whole infrastructure falls flat on its face; no namespace protection, ...). Also, not everyone uses - or even wants to use - git. I for one have banned git from all my projects, because its too easy to lie (yes, rebasing is lying).

"For me, programming in Perl is like my cooking. The result may not always taste nice, but it's quick, painless and it get's food on the table."

Comment on Re: Are you using Perl 6 in production?

Replies are listed 'Best First'.
Re^2: Are you using Perl 6 in production? by RonW (Parson) on May 23, 2016 at 22:33 UTC
I lost my enthusiasm for Perl6 years ago. And I've not yet more than dabbled in the officially released Perl6. As for contributing modules to Perl6, the guide claims that the plan is to create a Perl6 equivalent of CPAN. Also, I found the note: You can also already upload your Perl 6 modules to Perl 5's PAUSE, selecting `Perl6` directory during the upload. That will ensure your module is indexed in Perl 6's space and not Perl 5's.	[reply]
Re^2: Are you using Perl 6 in production? by Zoffix (Acolyte) on May 28, 2016 at 17:13 UTC
GitHub-based system is only temporary, until Perl 6 version of CPAN infrastructure is built. Also, you're not forced to use GitHub. There's support for GitLab as well, and we can add other services too, if needed.	[reply]
Re^2: Are you using Perl 6 in production? by Anonymous Monk on May 28, 2016 at 18:37 UTC
Yes git rebase is a type of lie, but it is white lie that is far more useful than the truth. (you shouldn't rebase any branch that isn't a temporary working branch though) Keeping the history clean is a far worthier goal than never rewriting history. ( In fact if I had to work with a DVCS that didn't support rebasing, I would recreate the commits by hand, which is tedious and error prone. ) In fact I prefer branches to be merged into master with git merge --ff-only --no-ff which has the effect of saying "this whole temporary branch is actually only one commit that was entirely made sometime after the last commit on master". It doesn't squash the commits, it just makes them easier to skip over when doing git bisect. I can only imagine how screwed up the history would be on a long-lived temporary branch if you kept merging from master instead of rebasing.	[reply]