Message-Passing

[Sean Kelly]

On Jan 25, 2012, at 2:49 AM, Manu wrote:

> On 23 January 2012 02:00, Timon Gehr <timon.gehr at gmx.ch> wrote:
> Erlang *has* been used in multiple large projects and it is likely that you make use of some service that is powered by erlang on a daily basis. It is successful in its niche. Copying its message passing API is reasonable and safe: Its concurrency model is the main selling point of erlang.
> 
> http://programmers.stackexchange.com/questions/112417/real-world-applications-of-erlang
> 
> Oh come on.. It's niche, unfamiliar to most people, and we're talking about name and argument list clarity with respect to what would be instinctive to the most users, not 'model' or API design, that's obviously fine.

Personally, I expected receiveOnly to see infrequent use compared to receive.  At least in my own code, it's rare that I'd want a receive call to throw if there's any message in the queue other than the one I'm looking for.  So the naming scheme was a mistaken assumption of popular use.


> C# is awesome because it gets this right. I think that's its single
> greatest achievement, and can not be understated.
> 
> 
> I couldn't find any information about a C# API for the same functionality. Can you help me out?
> 
> I'm not referring to this API in particular, I'm referring to the fairly universal application of the principle within the C# libraries. Most people I've ever talked to agree that one of it's biggest selling points, and possibly even the key reason they use it; because it was so accessible and productive from the instant they tried it out.
> You shouldn't need to read anything. Pressing '.' in the IDE shows lists of classes/methods/etc, and common sense writes your code. This requires that the function names make perfect sense, and the argument lists are as you intuitively expect.
> 
> If I: send(tid, myThing);
> I expect to: myThing = receive!SomeThing();
> 
> How can you argue that it's not intuitive to receive what you sent?

We could overload receive even more so that if it has only one argument and that argument is not a callable type, it does receiveOnly.  That might be deceptive however.  What I like about "receiveOnly" is that the name itself suggests that anything other than the specified type is not expected, and so some measure will probably be taken.  receive!T says to me "look for a message of this type and block if it's not present."


> There's nothing in: send(tid, something); that suggests the expected compliment API should take a var-arg list of undefined things. It's not clear from receive()'s signature that it should receive delegates, it looks like it could receive anything. The delegate signature is un-knowable from the functions own signature, nor what the delegates are even supposed to do.

This is an artifact of templates.  I doubt C# has this issue because C# doesn't have templates.


> Also, the name 'receiveOnly' doesn't actually make sense unless you *already know* that receive() is effectively receiveMulti. If I was scrolling through the pop-up list of methods, I would not confidently predict what that does.

Matter of opinion I suppose.  See above.