3 ms·
>I have a hunch that the language would be better off being explicit about message passing and keep it separate from "invoke an async method". What would be th
by ivanbakel 6y ago
>I have a hunch that the language would be better off being explicit about message passing and keep it separate from "invoke an async method".
What would be the benefit of this? (I haven't read the proposal in detail, but) If you can invoke an async method of an actor, it still has to be run in serial with the execution of messages to avoid races.
Besides, in the implementation I doubt that "messages" will be anything more than delayed async methods (and the implementation notes seem to support this). Actual actor systems rarely treat messages as first-class serializable entities - unless they hope to execute across multiple machines.
- sriku 6y agoYou're right on both counts. The mechanism of implementation will be very close .. which is what is in the proposal too. Having programmed in Erlang, I feel that the notation (i.e. syntax) influences moment to moment thinking. So if there is overlapping notation between method invocation and message passing, I expect increased opportunity to code and design incorrectly, resulting in subtle bugs. Making "async message passing" syntactically explicit and obivous clarifies a lot and prevents expectations of calling other methods, facing compiler errors, or worse having to deal with specified behaviours that may not be what I had in mind. Edit: one example of this confusion in the spec is the whole part about inheritance in actors ... which looks like a terrible idea to me.