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

A Complete Course of the Raku programming language

course.raku.org

Post reply on HN
Print view View original

101–110 of 110 posts

Re: A Complete Course of the Raku programming language

#101

Post by valenterry »

raiph wrote: post #90
valenterry wrote: post #82

Earlier quoted context omitted.

That must mean that it blocks and wait for the result. That doesn't "solve" the problem though.

It's a cooperative yield point so while the code containing the `await` blocks and waits, the underlying thread/core is released and "stolen" by the standard scheduler for other work, and then resumed when the processes it's waiting for complete or are cancelled. What problem is there beyond that?

I doubt that this is the case. Before I answer, let me ask you back: Why don't all languages just do it like that? Sounds pretty easy, no?

Re: A Complete Course of the Raku programming language

#102

Post by bmn__ »

valenterry wrote: post #101
raiph wrote: post #90

Earlier quoted context omitted.

It's a cooperative yield point so while the code containing the `await` blocks and waits, the underlying thread/core is released and "stolen" by the standard scheduler for other work, and then resumed when the processes it's waiting for complete or are cancelled. What problem is there beyond that?

I doubt that this is the case. Before I answer, let me ask you back: Why don't all languages just do it like that? Sounds pretty easy, no?

It is not okay to continue to sow doubt. I require you taking eight minutes to download the language and validating/disproving the claims.

Re: A Complete Course of the Raku programming language

#103

Post by valenterry »

bmn__ wrote: post #102
valenterry wrote: post #101

Earlier quoted context omitted.

I doubt that this is the case. Before I answer, let me ask you back: Why don't all languages just do it like that? Sounds pretty easy, no?

It is not okay to continue to sow doubt. I require you taking eight minutes to download the language and validating/disproving the claims.

That is your opinion. Mine is that it is okay to "sow doubt", similar to that it is okay to "sow doubt" when someone claims they built a perpetuum mobile.

But since you are asking me to download the language so politely: I think this is not necessary. A look in the documentation (https://docs.raku.org/language/concurrency) seems to be enough:

> The subroutine await is almost equivalent to calling result on the promise object returned by start but it will also take a list of promises and return the result of each

So "await" is equivalent to calling "result". What does calling "result" do?

> result blocks the current thread of execution until the promise is kept or broken

This stands in direct contradiction to what was said in the thread here:

> so while the code containing the `await` blocks and waits, the underlying thread/core is released

Unless the OP referred to a _different_ await, I would say: case closed.

Re: A Complete Course of the Raku programming language

#104

Post by lizmat »

valenterry wrote: post #101
raiph wrote: post #90

Earlier quoted context omitted.

It's a cooperative yield point so while the code containing the `await` blocks and waits, the underlying thread/core is released and "stolen" by the standard scheduler for other work, and then resumed when the processes it's waiting for complete or are cancelled. What problem is there beyond that?

I doubt that this is the case. Before I answer, let me ask you back: Why don't all languages just do it like that? Sounds pretty easy, no?

Because it is not easy to do. Have you tried it?

Re: A Complete Course of the Raku programming language

#105

Post by webmaven »

lizmat wrote: post #84
webmaven wrote: post #70

Earlier quoted context omitted.

> If you insist on comparing it to Perl, you could consider it "Perl Re-Imagined". Just like "The Lord Of The Rings" is a re-imagination of "The Hobbit". The Lord of the Rings is a sequel to The Hobbit, rather than a re-imagining. Of course there was a bit of re-imagining necessarily involved, much like the relationship between Star Trek: The Original Series and it's sequel The Next Generation.

As a Tolkien aficionado, Larry Wall I think knew what he was saying when he made this comparison. I think that if you compare https://en.wikipedia.org/wiki/The_Hobbit#Plot with https://en.wikipedia.org/wiki/The_Lord_of_the_Rings#Plot , you'll get an appreciation as to what Larry Wall meant.

Are you attributing the comparison in your comment to Larry Wall?

Re: A Complete Course of the Raku programming language

#106

Post by valenterry »

lizmat wrote: post #104
valenterry wrote: post #101

Earlier quoted context omitted.

I doubt that this is the case. Before I answer, let me ask you back: Why don't all languages just do it like that? Sounds pretty easy, no?

Because it is not easy to do. Have you tried it?

See my other post - it doesn't look as if raku is doing what was claimed in this thread here.

Re: A Complete Course of the Raku programming language

#107

Post by lizmat »

p6steve wrote: post #87
space_ghost wrote: post #34

Earlier quoted context omitted.

Raku also suffers from a lack of ecosystem. Perl5 and Node have huge advantages there.

'use Inline::XXX;' gives raku coders access to Perl5 (CPAN) and python modules

Actually, it is even simpler than that. If you have the Inline::Perl5 module installed, then the only thing you need to do to load a Perl module, is to use the :from adverb in the -use- statement, e.g.:

    use DBI:from;

Re: A Complete Course of the Raku programming language

#108

Post by raiph »

valenterry wrote: post #101
raiph wrote: post #90

Earlier quoted context omitted.

It's a cooperative yield point so while the code containing the `await` blocks and waits, the underlying thread/core is released and "stolen" by the standard scheduler for other work, and then resumed when the processes it's waiting for complete or are cancelled. What problem is there beyond that?

I doubt that this is the case. Before I answer, let me ask you back: Why don't all languages just do it like that? Sounds pretty easy, no?

> Why don't all languages just do it like that?

I think the main problem has been that it requires building an appropriate concurrency design into the foundation of a language.

For most PLs, concurrency is somewhat of an afterthought, and even for those where concurrency was addressed from the get go, the design nevertheless doesn't support work stealing, or, if it does, doesn't support doing so at the language level.

> I doubt...

Scepticism is healthy. :)

But regardless of my speculation about why most PLs don't go this route:

* The general technique (called "work stealing"[0]) was first implemented last century;

* PLs can support it directly at the language level provided they have suitable foundations;

* Raku is one such PL.

The first version of Raku (Raku Christmas, released Christmas Day 2015) already eliminated the need for function colouring. While the first version included an array of concurrency, async, and parallel processing features, including an `await` keyword, there has never been an `async` keyword in Raku. This is unusual, but Raku is not the only recently released PL to do so.

Work stealing semantics for `await` were only formally introduced in Raku Diwali, released Diwali day 2018, and the corresponding Rakudo compiler. Again, this makes Raku unusual, but not unique.

(What is perhaps unique is that Raku programs can include both old and new semantics in the same program. Raku has a radically different take on language evolution and backwards compatibility such that incompatible changes don't mean modules are incompatible with each other. Not easy to do, but possible, as demonstrated by Raku programs that make use of both Christmas and Diwali modules.)

> Sounds pretty easy, no?

It is easy for users. Once it's implemented in a language.

But it's not easy for language designers and implementers. (And it's essentially impossible to introduce if a PL has already adopted older approaches to concurrency.)

[0] https://en.wikipedia.org/wiki/Work_stealing

Re: A Complete Course of the Raku programming language

#109

Post by raiph »

valenterry wrote: post #103
bmn__ wrote: post #102

Earlier quoted context omitted.

It is not okay to continue to sow doubt. I require you taking eight minutes to download the language and validating/disproving the claims.

That is your opinion. Mine is that it is okay to "sow doubt", similar to that it is okay to "sow doubt" when someone claims they built a perpetuum mobile. But since you are asking me to download the language so politely: I think this is not necessary. A look in the documentation ( https://docs.raku.org/language/concurrency ) seems to be enough: > The subroutine await is almost equivalent to calling result on the prom…

(Edited to fix footnotes)

> blocks the current thread of execution

That's a green thread.[1]

To quote Wikipedia[2]:

> a thread of execution is the smallest sequence of programmed instructions that can be managed independently by a scheduler

This is the definition the doc is using.

The thread of execution that is blocked is a green thread -- the sequence of instructions containing the `await` that is managed by a scheduler managed by Raku.

> This stands in direct contradiction to what was said in the thread here:

>> so while the code containing the `await` blocks and waits, the underlying thread/core is released

> Unless the OP referred to a _different_ await

No, what I meant by "underlying thread/core" is an OS thread as against a green thread, and what I meant by "released" wasn't that it was released back to the OS but instead that Raku's scheduling sees the `await`, blocks the enclosing green thread, and immediately unblocks some other green thread by "stealing"[3] the OS thread to run that other green thread instead.

I hope I've now reassured you that Raku(do) both eliminates the red/blue distinction and doesn't block OS threads.

Yes, it's unusual among PLs. No, it's not easy to design a PL to do this at a language level. Nor is it easy to implement. (For example, the Rakudo implementation involves taking a continuation[4].)

But it is possible, and Raku has never had the red/blue distinction, and has had work stealing semantics for `await` since 2018.

[1] https://en.wikipedia.org/wiki/Green_threads

[2] https://en.wikipedia.org/wiki/Thread_(computing)

[3] https://en.wikipedia.org/wiki/Work_stealing

[4] http://jnthn.net/papers/2018-concurrency-guts.pdf#page=67

Post reply on HN