Some good ideas here. Personally, I don’t really understand why you would want objects and actors. The documentation drops off a cliff at some point so looks like it’s not quite done.
It doesn’t really argue explicitly for the combination, but one of their papers, “Deny capabilities for safe, fast actors” uses objects as the unit onto which a capability model is attached, in order to allow mutability while maintaining safety from data races.
Interesting. I don’t have time to read the paper now but given that an object is just a tuple I find it suspicious that one would need objects for that.
The word “object” in capability-based systems isn’t necessarily 1:1 with OOP. They’re often event loops, and can also be described as “services” or “actors”. In the case of Pony it’s using the term “actor” for objects with asynchronous behaviors.
I wouldn’t get too caught up on it.
The documentation drops off a cliff at some point
Specifically, the tutorial is blank after the subsection Expressions – Sugar. The sections of the tutorial with content are Getting started, Types, Capabilities, and most of Expressions. The most important missing sections are Actors, Garbage collection and C-FFI.
Dunno the justification for objects; but how do you lockless cooperative multiprocessing that scales seamlessly to many, many cores without actors?
This is the first time I’ve heard of it, but it seems really interesting. I’ve only just read the readme, mind. I have a couple years experience with Akka actors (for Scala / Java) and it had been great. Finding actor code a lot easier to reason about (and test!) than lock based code.
I can’t speak for @apy but I read the comment as meaning they don’t understand the need for the combination of the two, as in objects && actors.
@djm is correct, I’m not saying why objects or actors, but why both of them.
Graydon made a really nice post on Reddit about Pony and early Rust: http://www.reddit.com/r/rust/comments/34rszb/pony_type_and_memory_safe_language/cqxkmm8