On Friday, 8 November 2013 at 08:22:56 UTC, Bienlein wrote:
>>It seems like a pretty simple change so far, though I guess we'll see today. As >a demo, I'm creating both a ThreadMultiplexer and a FiberMultiplexer.
>
> That would be awesome. Something similar to lightweight threads
> as in Go or Rust and I'm all happy with D ;-).

Has someone implemented this?

On Monday, 19 August 2013 at 03:11:00 UTC, Luís Marques wrote:
> Can anyone please explain me what it means for the D language to follow the Actor model, as the relevant Wikipedia page says it does? [1]
>
> [1] http://en.wikipedia.org/wiki/Actor_model#Later_Actor_programming_languages

The page is largely unverified, i.e. nobody cares that it is full of errors…

D does not follow the actor model in any way shape or form…

When I come to think of it, browser based Javascript might be considered to follow the Actor model at a high granularity using web-workers or even just http.

But I think Hewitt's main idea was that it should be designed to be fault tolerant.  The system of actors should continue to work well when an actor crashes and restarts.

I think most «actor»-implementations fail at that. It is difficult to create an efficient «library solution» that makes the system fault tolerant.

On Saturday, 11 November 2017 at 13:31:20 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 19 August 2013 at 03:11:00 UTC, Luís Marques wrote:
>> Can anyone please explain me what it means for the D language to follow the Actor model, as the relevant Wikipedia page says it does? [1]
>>
>> [1] http://en.wikipedia.org/wiki/Actor_model#Later_Actor_programming_languages
>
> The page is largely unverified, i.e. nobody cares that it is full of errors…
>
> D does not follow the actor model in any way shape or form…

Wat? std.concurrency is message passing where an actor is either a Fiber or Thread.

Am 11.11.2017 um 13:28 schrieb Nordlöw:
> On Friday, 8 November 2013 at 08:22:56 UTC, Bienlein wrote:
>>> It seems like a pretty simple change so far, though I guess we'll see today. As >a demo, I'm creating both a ThreadMultiplexer and a FiberMultiplexer.
>>
>> That would be awesome. Something similar to lightweight threads
>> as in Go or Rust and I'm all happy with D ;-).
> 
> Has someone implemented this?

I have a PR open for vibe.d to add Go style channels:
https://github.com/vibe-d/vibe-core/pull/25

It's just a quick draft so far and there are a few design questions in the comments at the top.

On Saturday, 11 November 2017 at 18:30:33 UTC, Dmitry Olshansky wrote:
> On Saturday, 11 November 2017 at 13:31:20 UTC, Ola Fosheim Grøstad wrote:
>> On Monday, 19 August 2013 at 03:11:00 UTC, Luís Marques wrote:
>>> Can anyone please explain me what it means for the D language to follow the Actor model, as the relevant Wikipedia page says it does? [1]
>>>
>>> [1] http://en.wikipedia.org/wiki/Actor_model#Later_Actor_programming_languages
>>
>> The page is largely unverified, i.e. nobody cares that it is full of errors…
>>
>> D does not follow the actor model in any way shape or form…
>
> Wat? std.concurrency is message passing where an actor is either a Fiber or Thread.

That's a library and it does not have much to do with actors, i.e. it does not ensure that every actor is an independent entity.

On Saturday, 11 November 2017 at 20:37:59 UTC, Ola Fosheim Grostad wrote:
> On Saturday, 11 November 2017 at 18:30:33 UTC, Dmitry Olshansky wrote:
>> On Saturday, 11 November 2017 at 13:31:20 UTC, Ola Fosheim Grøstad wrote:
>>> On Monday, 19 August 2013 at 03:11:00 UTC, Luís Marques wrote:
>>>> Can anyone please explain me what it means for the D language to follow the Actor model, as the relevant Wikipedia page says it does? [1]
>>>>
>>>> [1] http://en.wikipedia.org/wiki/Actor_model#Later_Actor_programming_languages
>>>
>>> The page is largely unverified, i.e. nobody cares that it is full of errors…
>>>
>>> D does not follow the actor model in any way shape or form…
>>
>> Wat? std.concurrency is message passing where an actor is either a Fiber or Thread.
>
> That's a library

So what? Should we say that c doesn’t support threads because they are implemented in the library.

> and it does not have much to do with actors, i.e. it does not ensure that every actor is an independent entity.

What’s not independent about thread? How it doesn’t ensure that?
To me std.concurrency is pretty much Erlang-style message passing, except for supervision trees.

On Saturday, 11 November 2017 at 21:47:53 UTC, Dmitry Olshansky wrote:
> On Saturday, 11 November 2017 at 20:37:59 UTC, Ola Fosheim
>>
>> That's a library
>
> So what? Should we say that c doesn’t support threads because they are implemented in the library.

Regular C is not a concurrent language.
D is not an actor based language.

Has nothing to do with library features.

>
>> and it does not have much to do with actors, i.e. it does not ensure that every actor is an independent entity.
>
> What’s not independent about thread? How it doesn’t ensure that?

What is independent about a thread? A process is independent (mostly).
How can it ensure that?