On Sunday, 4 June 2017 at 19:12:42 UTC, Jacob Carlborg wrote:
> Erlang has the philosophy of share nothing between processes (green processes), or task as you call it here. All allocations are process local, that makes it easier to know that a failing process doesn't affect any other process.

Indeed.  (I used 'task' here in a deliberately vague sense, in order to not be too Erlang- or D-specific.)

The obvious differences in how D handles things seem to make it rather hard to get the same ease of error handling, but it would be interesting to consider what might get us closer.

On 2017-06-04 21:24, Paolo Invernizzi wrote:

> If I'm not wrong, it also uses a VM, also if there's the availability of
> a native code compiler...
> If a VM is involved, it's another game...

Yes, it's running on a VM, the Beam.

-- 
/Jacob Carlborg

On Sunday, 4 June 2017 at 19:24:27 UTC, Paolo Invernizzi wrote:
> If I'm not wrong, it also uses a VM, also if there's the availability of a native code compiler...
> If a VM is involved, it's another game...

Not sure if I follow that.  If you only use safe code then there should be no difference between using a VM or not.  And what is a VM these days anyway? (e.g. hypervisors and micro code caches in CPUs etc)

Now, you might argue that some IRs are too complicated, and that a simple IR is easier to get right. Or that some concurrency models are more volatile than others. That is true, but it doesn't have much to do with using a VM.

So the only special thing about using a VM in this case is that it could allow an actor to migrate to another server while running. Which is another game...