Perl 6: The Next Node.js, Done Right
If you've been a programmer for more than a couple of years, then you remember when Node.js first appeared. Some folks were raging about how insanely fast their ecosystem was growing, while others confusedly shrugged, wondering why anyone would want to use a language made for scripting browsers for server side work.
I can easily dismiss Node's large ecosystem of reinvented wheels, but the underlying point of why it got popular is valid: the fewer languages you need for an app, the fewer (or less experienced) programmers you have to hire, the cheaper it is to make your app. The self-proclaimed "HTML programmer" who was copy-pasting JS snippets from blogs and forums, now of all a sudden became a full-stack Web developer. But is using a made-for-browsers language for all-purpose work the right approach?
If you follow news or social media, today you definitely saw an article that invariably had a stock photo of someone playing Jenga. To sum up: lawyers pressured a developer to rename an NPM package. Developer refused. Lawyers came to NPM admins, who obliged to do so. The enraged developer then unpublished all of their NPM packages and the huge swath of the Interweb that depended on those packages chaotically crumbled and sufficient mocking of the whole system ensued.
The whole ordeal made me think of how such a situation might have played out in the Perl community. Would PAUSE admins remove an indexed module due to a request from lawyers, even when the author is responsive? Knowing personalities of a few of them, I doubt so. A communication channel among the involved parties would've been established instead.
And were a critical package actually deleted by someone, we have BackPAN, GitPAN, and dozens of slow-refreshing mirrors. We wouldn't need to take NPM's "an unprecedented step" to restore order to chaos. The system would've worked fine for awhile, and the breakage would be restricted to telling people to specify an actual package URL to the cpanm client. Not to mention, the NPM package that caused most of the breakage was tiny and some question why that little bit of code was even a dependency in the first place.
Going back to ecosystems. Browsing NPM, I can barely find packages with documentation, let alone tests for them; and I'm not the only one questioning quality. The Perl community, on the other hand, is a community of comprehensive tests. The quality of packages without tests is viewed with inherent suspicion and I've participated in many group mockings of packages that had no tests. Not to mention things like CPANTS Kwalitee Game that has "has tests" metric.
So what does my rambling have to do with Perl 6? The answer is the Perl 6 JavaScript Backend. Lead by Paweł Murias, the project was recently accepted for a grant and is well on its way to being usable.
You write Perl 6 code for both your backend and your frontend. The Perl 6 meant for the frontend gets compiled to JavaScript, so it can run in any browser that hasn't yet implemented native Perl 6 scripting in its core (c'mon, I can dream!). This is a complete inversion of the Node's paradigm: instead of a limited browser language made all-purpose, an all-purpose language's subset is made available in browsers. Throw into the mix the maturity and test-oriented culture of Perl, and I think you've got Node.js, Done Right.
So is the Jenga of Node starting to tumble down? Are we starting to realize the fad popularity of a language isn't the sole reason why your company should use it? Is there a successor ready to replace Node? Right now, I can only speculate, but in a couple of years, I'm sure Perl 6 will be the shiny new tool of a full-stack Web developer.
I blog about Perl.
I think the issue with NPM here has shown a defect in the corporate patronage model of open source, rather than any defect in Javascript as a language. Perl (and Perl6) has done the hard work of building a community from the ground up, and we have a deploy stack that is apparently unencumbered legally. The distributed nature of CPAN would make what happened in NPM harder, although there have been times in the past that are not dissimilar, and we handled it better (See the whole Nagios plugin fiasco from a few years ago).
That said I doubt very much Javascript programmers are going to flock to Perl6, even when installing P6 modules are as easy as 'cpanm -llocal::lib $module'. The vast majority of people using JS or its derivatives (or next generation stuff like EC6) that I've spoken with have a very negative view of Perl, and are often shocked to hear I am still using it full-time. Although I am sure Perl6 has a ton of great features (I keep hearing how the project is going to generate dozens of PhD dissertations, and I am looking forward to reading those, should that actually happen) the next version of Javascript, ecmascript6 has a lot going for it as well. In fact when I started a new person project to learn a new language this year I have learned a ton about es6 from online docs and code examples, whereas my attempts to learn Perl6 and contribute meaningfully to work in progress modules (a port of DOM::Tiny) totally failed. So there's still a lot of work there. Really JS and in particular the next evolution EC6 has most of what I want from a dynamic language, but no so much that the learning curve is steep and that I write code that only someone with 10 years experience can understand. Right now I am suspect Perl6 is much more complex, although maybe I haven't busted through the learning curve yet and will have some major elevation soon.
I do think a P6 to JS trans compiler has some value, for example Amazon Lambda uses JS and node.js and it would be great to write functions in P6 and be able to target Lambda. Also I can see some value for projects like templating languages to make is so you can write templates on the server side but use them client side.
PAUSE has removed modules in a similar situation before, even with responsive authors.
But PAUSE has the same feature: an author can remove all of their stuff at their own discretion.
so something like: https://vaadin.com/home?