3 ms·

> If you're worried about cosmic rays mutating your actor state randomly I'm more worried about other pieces of code mutating the state "randomly" > the same

> If you're worried about cosmic rays mutating your actor state randomly I'm more worried about other pieces of code mutating the state "randomly" > the same would be true of that other process mutating the state of your database The difference with a database is that all of its data ("state") is always public. An OOP service, at least, usually holds some hidden state that may change its behavior but can't be inspected from the outside, which makes its behavior nondeterministic (modulo explicitly-documented contracts). If you're saying Actors (in Orleans or otherwise) don't generally have state that's inaccessible from the outside, then that seems like a reasonable mitigation for this problem

yodon 5y ago
If the objection is to hidden state and behavior that can't be entirely predicted from the outside by inspection of public properties it feels to me like your objection is less about OOP and more about abstractions in general. I'm sure you've thought about this already and have strong opinions here, so please read this as me engaging in a conversation rather than me trying to lecture. The value of abstractions is the consumer doesn't need to understand the mechanism inside the abstraction, and the downside of abstractions is the consumer doesn't get to understand the mechanism inside the abstraction. If one always expects to be able to see through the veil, I think one is in effect saying I won't allow abstractions. That's powerful when the size of the system is such that it can be understood in its entirety, but it's punishing when the size is orders of magnitude larger than can be understood completely without abstractions by one person. Actors, at least from my experience, are a helpful way to merge the abstractions of OOP and Services, but by default they are not intended to rid systems of abstractions.

yodon 5y ago

If the objection is to hidden state and behavior that can't be entirely predicted from the outside by inspection of public properties it feels to me like your objection is less about OOP and more about abstractions in general. I'm sure you've thought about this already and have strong opinions here, so please read this as me engaging in a conversation rather than me trying to lecture. The value of abstractions is the consumer doesn't need to understand the mechanism inside the abstraction, and the downside of abstractions is the consumer doesn't get to understand the mechanism inside the abstraction. If one always expects to be able to see through the veil, I think one is in effect saying I won't allow abstractions. That's powerful when the size of the system is such that it can be understood in its entirety, but it's punishing when the size is orders of magnitude larger than can be understood completely without abstractions by one person. Actors, at least from my experience, are a helpful way to merge the abstractions of OOP and Services, but by default they are not intended to rid systems of abstractions.