Well I should have clarified that I was basing that on my interpretation of the terms RPC and message queue. The important bit is that all these debates are obscured by imprecise terminology.
RabbitMQ supports reciving messages based on a pattern:
That doesn't match my definition of RPC, but OK. I consider RPC server-to-server, not server -> "smart" intermediary -> server. But I guess they want to to define RPC as request/reply. So again it's a terminology issue.
What deployed, modern systems use tuple spaces and are substantively different from a message queue? My impression is that "tuple spaces" were the historical name, from Gelertner's papers, but everyone just calls them message queues. Message queues have lots of different properties but the defining one, as in tuple spaces, is that there's an intermediary between 2 servers. The sender and receiver don't have to be up at the same time.
> What deployed, modern systems use tuple spaces and are substantively different from a message queue?
None that I know of, but that's because no one uses generative communication nowadays :)
> Message queues have lots of different properties but the defining one, as in tuple spaces, is that there's an intermediary between 2 servers.
That's a very loose definition that could classify a lot of things as message queues. Generative communication says nothing about how the semantics are implemented; they may use an intermediary, or they may not. The early version of C-Linda did not use intermediaries, and was intended for in-process communication. Of course, a practical, distributed implementation of generative communication uses intermediaries. But then again, depending on the implementation, it may be distributed across multiple intermediaries.
I would say a message queue would necessarily have monotonicity (the name surely implies it!), which generative communication does not have.
> The sender and receiver don't have to be up at the same time.
In academic parlance this is called time decoupling, and it is an awesome property. ZeroRPC has this as well thanks to 0mq.
I don't really know anything about RabbitMQ to comment. I think I've heard that some engineers at dotCloud tried it out for our distributed communication needs, and it just couldn't scale to our load. But that would've been a while ago, and it has probably improved substantially since.
OK fair enough. But just with regard to your original point -- people should "care" about higher level distributed systems abstractions, and they do (to an extent). I think the main example of a higher level abstraction in wide use is message queues (which I think of as a descendant of tuple spaces, but that point is immaterial).
If your only concept is RPC, that's just too low level and limited, and you're going to end up with a mess. You're right that "developers understand RPC" (in a naive way). But that's just because we are still in the early stages and knowledge hasn't had time to propagate. Some RPC systems have more of the naive properties that the OP was pointing to; some have learned from those mistakes.
RabbitMQ supports reciving messages based on a pattern:
http://www.rabbitmq.com/tutorials/tutorial-five-python.html
It also says it supports RPC:
http://www.rabbitmq.com/tutorials/tutorial-six-python.html
That doesn't match my definition of RPC, but OK. I consider RPC server-to-server, not server -> "smart" intermediary -> server. But I guess they want to to define RPC as request/reply. So again it's a terminology issue.
What deployed, modern systems use tuple spaces and are substantively different from a message queue? My impression is that "tuple spaces" were the historical name, from Gelertner's papers, but everyone just calls them message queues. Message queues have lots of different properties but the defining one, as in tuple spaces, is that there's an intermediary between 2 servers. The sender and receiver don't have to be up at the same time.