Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Larry Wall has approved renaming Perl 6 to Raku

github.com

Post reply on HN
Print view View original

231–240 of 463 posts

Re: Larry Wall has approved renaming Perl 6 to Raku

#231

Post by dnautics »

lliamander wrote: post #189
7thaccount wrote: post #53

Earlier quoted context omitted.

When someone says they want to work in Perl6/Raku, they likely have vastly different problems than someone using Erlang/Elixer. There is overlap of course (both general purpose), but I can't imagine using Erlang for scripting, while Raku is first class here.

I can't imagine scripting in Erlang. Or rather, I've seen it done and it wouldn't be my first choice. Elixir, on the other hand, has many nice features for scripting, such as better string handling, process pipe-lining, and an excellent set of first-class generic data structures (beyond just map and list). It also happens to have Erlang's fantastic concurrency model.

As a testament to this statement I wrote a Google maps API scraper to get a list of driving distances from a pair of csv tables - shortname + address and shortnames to and from, in about 1 hour, and the whole thing clocked in at 90 lines of code including about 40 lines of comments.

Re: Larry Wall has approved renaming Perl 6 to Raku

#232

Post by dnautics »

Willamin wrote: post #205
xyproto wrote: post #160

Earlier quoted context omitted.

I didn't know that Elixir had such a low-threshold for one-off programs. Have you tried Crystal? Both are on my list of programming languages to look into next, together with Elm, Reason and Zig.

Crystal is wonderful for one-off programs in my experience. Elixir had a long startup time for one-off scripts in my experience, but Elixir’s syntax is still one of my favorites for scripting.

Is a 100ms startup time really a big deal for something that is either going to be manually triggered or cronjobbed and expected to take on the order of minutes?

Re: Larry Wall has approved renaming Perl 6 to Raku

#233

Post by blahedo »

ether_at_cpan wrote: post #216
joshlemer wrote: post #50

Earlier quoted context omitted.

It's not uncommon to leap frog versions in such cases. PHP went from 5 to 7, for instance.

For those that can remember back that far, MacOS also jumped from 5 to 7. (7 was the first version that supported running multiple applications at once.. not counting the MultiFinder hack that came before it by a few years.)

It certainly did not. System 6 (including MultiFinder if you had enough RAM to support it ;) was active for several years in the early 90s before System 7 came out. The label "MacOS", meanwhile, didn't show up until a few years after that.

Re: Larry Wall has approved renaming Perl 6 to Raku

#234

Post by yjftsjthsd-h »

ether_at_cpan wrote: post #216
joshlemer wrote: post #50

Earlier quoted context omitted.

It's not uncommon to leap frog versions in such cases. PHP went from 5 to 7, for instance.

For those that can remember back that far, MacOS also jumped from 5 to 7. (7 was the first version that supported running multiple applications at once.. not counting the MultiFinder hack that came before it by a few years.)

What? https://en.wikipedia.org/wiki/System_6

Re: Larry Wall has approved renaming Perl 6 to Raku

#235

Post by dnautics »

weff_ wrote: post #113
7thaccount wrote: post #53

Earlier quoted context omitted.

When someone says they want to work in Perl6/Raku, they likely have vastly different problems than someone using Erlang/Elixer. There is overlap of course (both general purpose), but I can't imagine using Erlang for scripting, while Raku is first class here.

I'm trying to understand, what kind of scripting requires first-class concurrency that isn't fulfilled by say Python?

Well just from experience untangling async calls in python is a nightmare and sometimes hard to reason about. The red/blue function problem is real. Meanwhile dispatching concurrent long-running scripting tasks is basically trivial in elixir (Enum.map over Task.async, then Enum.map over Task.await)

Re: Larry Wall has approved renaming Perl 6 to Raku

#237

Post by Grinnz »

notyourday wrote: post #229
Grinnz wrote: post #163

Earlier quoted context omitted.

I'm not sure what gave you the idea that just because Mojolicious is Perl, it would have "a pile of corner cases" while a "simple nodejs app" wouldn't. Mojolicious is built from the ground up to be effortlessly asynchronous and performant and handle all common needs. Don't punish it for the horrible CGI.pm that has been removed from core Perl. Yes, Perl's threading support is terrible, and I do wish it was as effortl…

> I'm not sure what gave you the idea that just because Mojolicious is Perl, it would have "a pile of corner cases" while a "simple nodejs app" wouldn't. Mojolicious is built from the ground up to be effortlessly asynchronous and performant and handle all common needs. Don't punish it for the horrible CGI.pm that has been removed from core Perl Because there have not been million people with different levels of skill…

Okay, I see. You should use what most easily provides the features you want, to be sure, and it certainly has not been battle tested the way, say, Catalyst has. But I think you are still selling it short. Mojolicious is foremost about consistency and practicality, beauty (if you would consider it that) is simply a side effect; and it is probably in more use than you think.

Re: Larry Wall has approved renaming Perl 6 to Raku

#238

Post by ether_at_cpan »

bifrost wrote: post #4
overcast wrote: post #3

Can someone give the rest of us some context on this?

Perl5 -> Perl6 has been highly contentious. Perl6 is basically a different language much to the chagrin of many Perl users. A lot of Perl users are entrenched in Perl5. FWIW: I'm unclear why people continue to use Perl at all, I moved on in 2011.

> I'm unclear why people continue to use Perl at all

Because there's a huge amount of applications and websites still built in it, and it's still a great language so new projects are written in it all the time.

source: my very prosperous career, which has been almost entirely in Perl for the last 15 years

Re: Larry Wall has approved renaming Perl 6 to Raku

#239

Post by spider-mario »

WorldMaker wrote: post #153
StevePerkins wrote: post #93

Earlier quoted context omitted.

Perl 5 was released in 1994. At this point, the "5" isn't really a version number anymore. It's just part of the name. If you did a "major version bump" from here, you'd probably have to bring the "5" along for the ride. Like Java version 2, where you had J2EE version for years. In reality, there probably never will be another major version bump of Perl 5, in the marketing sense. The minor version number is really th…

Which in turn suggests the Java (and others') solution of dropping the 5 and making the minor version the new major version. Look out for Perl 31.0 soon.

Java even got rid of two numbers:

J2EE 1.4 -> Java EE 5

Both “2” and “1.”.

Re: Larry Wall has approved renaming Perl 6 to Raku

#240

Post by deaddodo »

joshlemer wrote: post #50
jolmg wrote: post #46

Earlier quoted context omitted.

> Larry has now agreed with the change and Perl 6 will be renamed to "raku" and Perl 5, which has regular, major releases every year, will now be able to simply be "Perl" and be free to continue on its own way. I hope that doesn't mean that when Perl needs a major number version change again, they'll chose 6. It would be pretty confusing to have 2 Perl 6.

It's not uncommon to leap frog versions in such cases. PHP went from 5 to 7, for instance.

They didn't "skip" php6.

The primary goal of PHP6 was to implement full unicode support and drop mbstring. However, that took much longer than expected and multiple major features ended up getting backported to 5.3, 5.4 and 5.6; to the point that PHP 7 became the new feature version while PHP6 was worked on. They eventually gave up and PHP7 was released with unicode support built fairly deep, but basic string types and the like still being byte arrays.

PHP7 was PHP6, without the native and full unicode coverage requirement.

Post reply on HN