Is Pony still an actively developed language? I remember watching several talks while they brought the language up to release, and read several of the accompanying papers. However, I thought with the primary corporate sponsor dropping the language it had gone basically EOL. Which was a pretty large bummer as I was very interested to see how the reference capability model of permissions and control worked at large scale for concurrency control and management (as well as its potential application to other domains).
Please change the title to the original, "Actors: A Model Of Concurrent Computation In Distributed Systems".
I'm not normally a stickler for HN's rule about title preservation, but in this case the "in distributed systems" part is crucial, because IMO the urge to use both the actor model (and its relative, CSP) in non-distributed systems solely in order to achieve concurrency has been a massive boondoggle and a huge dead end. Which is to say, if you're within a single process, what you want is structured concurrency ( https://vorpus.org/blog/notes-on-structured-concurrency-or-g... ), not the unstructured concurrency that is inherent to a distributed system.
Actor model is one of these things that really seduces me on paper, but my only exposure to it was in my consulting career, and that was to help migrate away from it. The use case seemed particularly adapted (integration of a bunch of remote devices with spotty connection), but it was practically a nightmare to debug... which was a problem since it was buggy.
To be fair, the problem was probably that particular implementation, but I'm wondering if there's any successful rollout of that model at any significant scale out there.
> It is generally believed that the next generation of computers will involve
massively parallel architectures.
To this day - we have only taken advantage of parallel architectures in GPUs - a lot of software still runs on single CPU threads. most programming languages- are made optimized for single threads - yeah we might have threads, virtual threads, fibers etc - but how many people are using those on a daily basis?
I was under the impression that parallel and concurrent code was the dominant paradigm for programming tasks currently going in most of the semi-mainstream domains. I am certainly willing to concede that I could just be in a bubble that thinks about and designs for concurrency and parallelism as a first class concern, but it doesn’t seem that way.
I mean one of the large features/touted benefits for Rust is the single mutable XOR multiple immutable semantics explicitly to assist with problems in parallel/concurrent code, all of the OTP languages are built on top of a ridiculously parallel and distributed first ‘VM’. It strikes me as peculiar that these types of languages and ecosystems would be so, apparently, popular if the primary use case of ‘safe’/resilient parallel/concurrent code was not a large concern.
> It captures the nondeterminism in the order of delivery of communications. The Subsequent transition captures fairness arising from the guarantee of delivery. We provide a denotational semantics for our minimal actor language in terms of the transition relations.
Juicy paper, not to mention the declassification. It really reminds me of asyncmachine.dev which has actors, relations, transitions, and embraces non-determinism.
12 comments
[ 3.3 ms ] story [ 50.4 ms ] threadhttps://en.wikipedia.org/wiki/Gul_Agha_(computer_scientist)
https://www.ponylang.io/
I'm not normally a stickler for HN's rule about title preservation, but in this case the "in distributed systems" part is crucial, because IMO the urge to use both the actor model (and its relative, CSP) in non-distributed systems solely in order to achieve concurrency has been a massive boondoggle and a huge dead end. Which is to say, if you're within a single process, what you want is structured concurrency ( https://vorpus.org/blog/notes-on-structured-concurrency-or-g... ), not the unstructured concurrency that is inherent to a distributed system.
To be fair, the problem was probably that particular implementation, but I'm wondering if there's any successful rollout of that model at any significant scale out there.
To this day - we have only taken advantage of parallel architectures in GPUs - a lot of software still runs on single CPU threads. most programming languages- are made optimized for single threads - yeah we might have threads, virtual threads, fibers etc - but how many people are using those on a daily basis?
I was under the impression that parallel and concurrent code was the dominant paradigm for programming tasks currently going in most of the semi-mainstream domains. I am certainly willing to concede that I could just be in a bubble that thinks about and designs for concurrency and parallelism as a first class concern, but it doesn’t seem that way.
I mean one of the large features/touted benefits for Rust is the single mutable XOR multiple immutable semantics explicitly to assist with problems in parallel/concurrent code, all of the OTP languages are built on top of a ridiculously parallel and distributed first ‘VM’. It strikes me as peculiar that these types of languages and ecosystems would be so, apparently, popular if the primary use case of ‘safe’/resilient parallel/concurrent code was not a large concern.
Juicy paper, not to mention the declassification. It really reminds me of asyncmachine.dev which has actors, relations, transitions, and embraces non-determinism.