3 ms·

The benefit would be if there was a language where everything is an actor. It would greatly simplify your programming model. I'm thinking of the early version

The benefit would be if there was a language where everything is an actor. It would greatly simplify your programming model. I'm thinking of the early versions of Smalltalk which tilted towards this direction. Why did they abandon 'active objects'? I guess the hardware just wasn't there yet.

zozbot234 4y ago
Rust effectively accomplishes this, because mutating a value that's accessible by a different thread requires both interior mutability and a separate Sync trait, meaning that accesses will be properly synchronized. Some types implement this (atomic types, Arc, Mutex, Rwlock) but the default is not to, so the default is that data may only be mutated by a single thread at any given time.
- galaxyLogic 4y ago
  I think there is more to Actors than just single-thread-access. Namely only the code of a given actor(-class) should be able to read and write the internal state of "instances" of that class. Why because then only the code-unit/module that defined the state variables can depends on their definition. A bit like "objects" internals can only be accessed by methods of its class.
jerf 4y ago
There are languages where everything is an actor, like Erlang. I said what I said because I worked in them professionally for many years. While there is incremental benefit to being 100% actors versus 90% actors, I don't think it's that impressive of an incremental benefit, and is easily overwhelmed by many other factors. That's why I work mostly in Go and borrow actor structures when helpful. That turns out to be every non-trivial program I've written so far... but there's no particular benefit and often non-trivial costs in trying to write the whole program as actors, rather than using actors as useful servers. The simplification of being able to look at something and just know it's an actor I don't find very helpful. It's not hard to document these things, or see them in the structure of the code. By contrast, 90% pure functional programming is a pretty terrible paradigm. You really need to push that number up to get the benefits. As you approach 100% I think the benefit starts to take off. But, speaking very sloppily since "percent pure functional programming" is kind of difficult to precisely define, 90% is like the worst case scenario. 20%, which is to say mixing it in to other paradigms when useful without commitment and without paying much price and just harvesting the low hanging fruit can be very nice, and 99.9% can be very powerful, but 90% is the worst case, where you're paying most of the price but getting few of the benefits of true commitment. This is what I mean by seeing a lot of benefit in going the full way. I don't see this benefit to actors. They work just fine embedded into large programs and deliver the vast bulk of their benefit without having to structure the entire program around them. Definitely still worth learning; I consider them a core technique in concurrency programming. When you can easily afford the message marshaling and concurrency expenses, they are one of the easiest ways to get concurrency without complexity. And most of the time, you can afford those costs.

zozbot234 4y ago

Rust effectively accomplishes this, because mutating a value that's accessible by a different thread requires both interior mutability and a separate Sync trait, meaning that accesses will be properly synchronized. Some types implement this (atomic types, Arc, Mutex, Rwlock) but the default is not to, so the default is that data may only be mutated by a single thread at any given time.

galaxyLogic 4y ago
I think there is more to Actors than just single-thread-access. Namely only the code of a given actor(-class) should be able to read and write the internal state of "instances" of that class. Why because then only the code-unit/module that defined the state variables can depends on their definition. A bit like "objects" internals can only be accessed by methods of its class.

jerf 4y ago

There are languages where everything is an actor, like Erlang. I said what I said because I worked in them professionally for many years. While there is incremental benefit to being 100% actors versus 90% actors, I don't think it's that impressive of an incremental benefit, and is easily overwhelmed by many other factors. That's why I work mostly in Go and borrow actor structures when helpful. That turns out to be every non-trivial program I've written so far... but there's no particular benefit and often non-trivial costs in trying to write the whole program as actors, rather than using actors as useful servers. The simplification of being able to look at something and just know it's an actor I don't find very helpful. It's not hard to document these things, or see them in the structure of the code. By contrast, 90% pure functional programming is a pretty terrible paradigm. You really need to push that number up to get the benefits. As you approach 100% I think the benefit starts to take off. But, speaking very sloppily since "percent pure functional programming" is kind of difficult to precisely define, 90% is like the worst case scenario. 20%, which is to say mixing it in to other paradigms when useful without commitment and without paying much price and just harvesting the low hanging fruit can be very nice, and 99.9% can be very powerful, but 90% is the worst case, where you're paying most of the price but getting few of the benefits of true commitment. This is what I mean by seeing a lot of benefit in going the full way. I don't see this benefit to actors. They work just fine embedded into large programs and deliver the vast bulk of their benefit without having to structure the entire program around them. Definitely still worth learning; I consider them a core technique in concurrency programming. When you can easily afford the message marshaling and concurrency expenses, they are one of the easiest ways to get concurrency without complexity. And most of the time, you can afford those costs.