Oh interesting to hear from a RabbitMQ developer, thanks for taking the time to reply.

Well, I'll try to elaborate on my rant. Most of it from memory (been a year ago since I last touched AMQP).

Back then when I looked at AMQP (and used it for one project):

* It was very hard to find reasonable documentation.
The most accessible I found was the (excellent)
http://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/ blog post.
This was what eventually got us off the ground. Imho a testament to the
shortcomings of the "official" documentation (where is it?).

* RabbitMQ only implemented AMQP 0.8. I cannot remember the exact differences
between 0.9 and 0.8 (and heck, good luck trying to find a document explaining
them even today). For us it boiled down to some clients simply not working
and it took a while to figure out what the problem even was.

* Client interoperability was generally spotty, even in clients supposed to be
compatible. It seems the idea of that whole spec-file stuff was to make the
protocol pluggable and flexible. However the only thing it seems to have
achieved is to make client development hell.
The client we eventually went with (py-amqplib) doesn't even use the
spec-file because "parsing takes too long".

* Moreover the sheer existence of http://www.rabbitmq.com/interoperability.html
is a testament to a flawed protocol. If I can't rely on a 0.8 client
to talk to a 0.8 server properly, then something is fundamentally wrong.

* There's a huge pile of semantic baggage (Exchanges, Bindings, Queues, Channels) that
left us with a giant "WTF" the more we used it. Yes, it can be made
work. But hell, talk about overengineering. Much simpler constructions
could have been used to achieve the same goals.

* As I just learned during my googling for this post, apparently some of the problems have even been acknowledged
by the officials and are supposed to be simplified in AMQP 1.0
(http://www.amqp.org/confluence/display/AMQP/Background+to+AM...).
But I'm not expecting much, to be honest.

So, that's just a few points that popped into my head immediately, there's more if I'd dig deeper. It's just a fundamentally bad protocol if I have ever seen one, and I'm honestly surprised to see people defend it even after the creators themselves (iMatix) acknowledge it to be a dead-end.

To put it from an different angle: When you think about what AMQP really does then how long would it take you to whip up a near-trivial but feature-equivalent protocol from scratch? I could think of many ways to skin that cat in a better way, with a simple, hackable, plain-text protocol.

You know, one of those protocols where I, as a developer, can even sniff and see what is going on at any time. Those are possible, as demonstrated by redis, memcached, STOMP, beanstalkd and many others.

I acknowledge that some complexity is unavoidable for advanced use-cases. Still, a good protocol layers the complexity in a way so that simple stuff remains simple and complex stuff becomes manageable. To me AMQP is a complete failure in both regards; you are confronted with the full complexity even for the most trivial use-case. And it seems for complex use-cases it adds a hefty layer of complexity of its own, rather than helping to wrap up.