I’m not sure yet if a minimalist interface will end up sufficient in practice, and not a complex enough interface that it could very well end up dictating the implementation (especially when performance considerations enter into play). For example, you’d probably need a signaling interface, so you can inquire the state of the actor (if it’s alive), you’d need a way to signal a shutdown command, you’d need a way to link one actor to another so an exception can trigger a reaction on another actor (and not only within the supervision tree which is insufficient), all of these are necessary so it will play nice in an actor tree/graph (which might lead to: do we also need a supervision tree interface?). If we used Elixir reference, it would be similar to the methods defined in Process
But once an interface is defined (even if it ends up converging on a a standard implementation), JuliaActors group can very well become something like JuliaArrays, with libraries that build on the Actor interface to provide all kind of specialized actors for each purpose, like DynamicSupervisors, Tasks, GenServers, GenStage (consumer-producer abstraction).
That said I might not be as interested in creating my own implementation of Actors as in the infra-structure around it, Actors for me are more of a means to an end. Stuff like Akka HTTP, Akka Streams, Erlang Term Storage/Mnesia, Phoenix PubSub are all tools that I really think would really complement Julia’s current strengths. I’ve been toying with implementing a Kafka consumer group similar to KafkaEx, which while only supporting very basic features of Kafka (below 1.0), it can provide a lot of reliability through the let-it-crash strategy. And I’m really interested in how a heavily ccall/threadcall/IO-based actor would behave (for example if you’d be forced to lock the primary Julia thread for it to work).