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

351–360 of 463 posts

Re: Larry Wall has approved renaming Perl 6 to Raku

#351

Post by dragonwriter »

labster wrote: post #252
weff_ wrote: post #206

Earlier quoted context omitted.

Ovid2 said Perl6 has a good concurrency model lliamander replied that Elixir does too and it's worth a look To that, 7thaccount replied that Perl6 and Elixir fill different niches. So far, it seems Perl6 fills a niche that requires scripting and first-class concurrency. My question then is: what is this niche that requires very solid concurrency but also scripting. In other words, what does Perl6 have in terms of con…

Does Python 3 have any operators that transform ordinary method calls into concurrent method calls? Perl 6/Raku does.

More to the point, does Python 3 have operators that transform sequential operations into operations that are both concurrent and parallelizable, and, in the case of iteration, provide control of parallelism parameters and whether results are constrained to be in-order or not.

To which the answer is “not only does Python not have them, but with the GIL CPython couldn't do much with them even if the language had them.”

Re: Larry Wall has approved renaming Perl 6 to Raku

#352

Post by Ovid »

7thaccount wrote: post #262
Ovid wrote: post #2

This has been a huge deal for the Perl community. First, it was thought that Perl 6 would be the replacement for Perl 5. But it was long ago recognized that there was no clear upgrade path from Perl 5 to Perl 6, so it was agreed that Perl 6 was a "sister" language to Perl 5 rather than the successor. Except that many people expected that Perl 6 would be the replacement, so that stalled many projects. So an "alias" fo…

Hey Ovid. I'm curious...if P6 had been performant and production worthy enough for your tau-station game, how much easier would the project be than with P5 + Moose? Just curious...I remember you saying years ago that you would've used it if you could've at the time.

The https://taustation.space/ game runs great on Perl 5, but yes, with a robust Perl 6, many things would have been easier to implement. But by "robust" I don't mean just the language—I also mean the ecosystem.

There is no DBIx::Class (or related schema loader) for Perl 6. I don't know how mature the web frameworks are. Or even basic stuff like Excel reader/writers (we use lots of Excel for backend data analysis).

On the other hand, most of the async stuff we currently use can be thrown out. With raku's gradual typing, our in-house type libraries can be tossed out. Our local modules for making it easier to write clean procedural and OO code could be thrown out.

And the raku code would be far more concise and easy to read. Here's a simple Point object in Moose:

    package Point {
        use Moose;
        use overload '""' => \&Str, fallback => 1;
        use Moose::Util::TypeConstraints;
        subtype "PointLimit" => as 'Num'
            => where   { $_ >= -10 && $_  message { "$_ must be a Num between -10 and 10, inclusive" };

        has [qw/x y/] => (
            is       => 'rw',
            isa      => 'PointLimit',
            required => 1,
        );

        sub Str {
            my $self = shift;
            return sprintf "[%f,%f]" => $self->x, $self->y;
        }
    }
raku:

    class Point {
        subset PointLimit of Rat where -10.0 .. 10.0;
        has PointLimit $.x is rw is required;
        has PointLimit $.y is rw is required;
    }
And for those who don't "grok" the above, here it is in Python 3, just so you can see how clean raku's OO syntax is:

    class PointLimit:
        def __init__(self, name):
            self.name =  name
        def __get__(self, point, owner):
            return point.__dict__.get(self.name)
        def __set__(self, point, value):
            if not -10

Re: Larry Wall has approved renaming Perl 6 to Raku

#353

Post by dragonwriter »

jtms wrote: post #316
core-questions wrote: post #285

Earlier quoted context omitted.

It must be time to take my Ruby skills and go and learn this. Is it really as easy as it sounds like it should be for a lazy, dynamic-typing sort of Ruby dev to pick up?

If you have never worked with a strongly typed language before there might be some getting used to that, but any pain is well worth it. Catching all your mistakes at compile time and not at runtime is so amazing. Oh and it’s literally 100x faster than Ruby in some cases.

> Catching all your mistakes at compile time and not at runtime is so amazing

It would be, but IME Crystal, or statically typed programming languages that don't have a type system at least as powerful as Haskells in general, don't get anywhere remotely close to that, and the overhead added to get what they do give is of dubious net benefit outside of large projects.

And even with Haskell, while you can express a much richer set of constraints in types, there's also more space for bugs in the type level programming.

Re: Larry Wall has approved renaming Perl 6 to Raku

#354

Post by petre »

xisukar wrote: post #197
petre wrote: post #129

Earlier quoted context omitted.

Why not before? Because Perl is you know, dead. Jokes aside, it's a pretty nice language apart from the !$double .@sigils. If I'd switch from Perl 5, I'd probably switch to Ruby, as Perl 6 oops Raku is quite slow.

> ... apart from the !$double .@sigils In this case, `!$double` isn't a sigil. `!` is just the old prefix operator for negating a value [1]. If you meant to write `$!double`, then it's the twigil [2] for class attributes [3]. Twigils could be considered as secondary sigils but they affect the scoping of a variable. In this instance, `!` is for class attributes and will only be found there. As for `.@sigils`, I've nev…

Ok, twigils, whatever. They're next to each other so they're double the crazyness. Like the $#last_index in Perl. In Raku the . and ! are used to designate a private or public variable within a class definition. I got it backwards, which sort of proves the whole point. Push a private array nested into another and you have a bunch of gibberish worse than in Perl, where you'd only prefix it with \. Use an auxilliary variable and it feels too verbose. OTOH @{$hash{array_ref}} dereferentiation in Perl is quite annoying. And no, $hash{array_ref}->@ is definitely not how you fix this mess. I agree that sigils offer some insight into what type of the variable you are looking at.

Great improvements are not enough compared to other languages, even Ruby which is quite slow itself. Have you wrote anything in Node, Dart or Lua? They feel like a F1 car where Raku is an 17th century cart.

Re: Larry Wall has approved renaming Perl 6 to Raku

#355

Post by dragonwriter »

cutler wrote: post #334
tombert wrote: post #140

Earlier quoted context omitted.

Heh, escript isn't so bad once you get used to it. Clojure would be a great language for small-ish scripts if it weren't the dog-slow startup times, and has excellent concurrency support. I hear that GraalVM might fix that but I sadly haven't had a chance to play with that yet.

Even if GraalVM fixes startup times aren't JVM languages just too long-winded for scripting? Perl, Python and Ruby dominate the scripting world for a reason - standard libraries for file, dir and pathname manipulation written in a concise language. Scripting is a style of coding, not just a means to an end. It is here that dynamic languages excel. Clojure is the leanest of the JVMs but doesn't it still rely on Java f…

> Even if GraalVM fixes startup times aren't JVM languages just too long-winded for scripting? Perl, Python and Ruby dominate the scripting world for a reason

Ruby is a JVM language, in that JRuby is a very complete competitive, current, and widely-used-in-production Ruby implementation.

Re: Larry Wall has approved renaming Perl 6 to Raku

#356

Post by SwellJoe »

diag wrote: post #71
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.

But that's because PHP6 was dumped after being in development for a while.

This is not entirely unlike that. Somewhere along the way, everybody realized Perl 6 was not the path forward from Perl 5, and so Perl 6 never really took the place of Perl 5, just like PHP6 never took the place of PHP 5. It looks like a pretty similar scenario, if you squint, I think.

It makes little difference for Perl that this experiment in a next generation version of the language is still alive and going its own way. The result is the same...people kept moving forward with version 5, and if it needs a new version, it can't use version 6 because 6 was already used for that other experiment (that failed to take the place of Perl 5).

Re: Larry Wall has approved renaming Perl 6 to Raku

#357

Post by techcode »

cgh wrote: post #301
msla wrote: post #109

Earlier quoted context omitted.

And this might save Raku. Lisp has a social problem: It's been called Lisp too long. People look at some simplified LISP 1.5-esque thing in a programming languages textbook and see a "pure" language (which isn't so pure compared to Haskell, but the creep of what "functional programming" means is its own post) which is completely useless. They don't see modern Common Lisp with its package management facility and its p…

> Calling it Raku is a chance to get what the Perl 6 team actually did out into the world without the stench of death following it. "Raku" = "cancer" in Polish. Not a lot of Polish enthusiasm forthcoming, I'd imagine.

I'd imagine that chances are high that whatever name you pick for something in one language - there would be another language in this world in which same or similar word means bad/offensive thing.

Re: Larry Wall has approved renaming Perl 6 to Raku

#358

Post by anonytrary »

kbd wrote: post #136

Naming matters. Nim changing from "Nimrod" matters. Cockroachdb's name is offputting. Perl 6's name has caused endless confusion and by itself sabotaged both Perl 5 and Perl 6. Perl 6 has interesting ideas but I don't even want to touch it because its naming issue is so toxic. I'm glad they're going to rename it.

Is there a TLDR on what's wrong with the name "Perl 6" for those of us who have zero context?

Re: Larry Wall has approved renaming Perl 6 to Raku

#359

Post by Ovid »

bborud wrote: post #175
Ovid wrote: post #2

This has been a huge deal for the Perl community. First, it was thought that Perl 6 would be the replacement for Perl 5. But it was long ago recognized that there was no clear upgrade path from Perl 5 to Perl 6, so it was agreed that Perl 6 was a "sister" language to Perl 5 rather than the successor. Except that many people expected that Perl 6 would be the replacement, so that stalled many projects. So an "alias" fo…

> This has been a huge deal for the Perl community. I wasn't aware that there was one beyond the poor sods charged with maintaining my youthful sins.

I get hired all the time to fix legacy systems in Perl or to build new systems in Perl.

We're still out there, but it's not "cool" to talk about.

Re: Larry Wall has approved renaming Perl 6 to Raku

#360

Post by bhaak »

emmelaich wrote: post #350
Willamin wrote: post #205

Earlier quoted context omitted.

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.

Crystal's startup time is not great though. 700ms vs 100ms for ruby. Compared with time crystal eval

You know that you are timing the compiler and not the compiled program here?

Rather try "echo 'puts 1' > puts.cr && crystal build puts.cr && time ./puts"

BTW, you can dramatically decrease the cold startup times of ruby if you call it with the options '--disable-gems --disable-rubyopt' if that's an option to you. For many scripts it certainly is.

But even on a 8 years old machine with spinning rust, after the ruby stuff is cached in the OS filesystem cache, my startup time are smaller than 10ms.

Post reply on HN