Pulsar and Rabbit MQ are fundamentally different products; viewing pulsar like a push based message queue is missing a lot of the features that make it so suitable for event driven architectures.
RabbitMQ simply does not like holding on to data. Performance craters with long queues. RabbitMQ is accurately a “message broker” and quite an excellent one at that. Tooling is fantastic, and the software (built on Erlang/OTP) is very reliable.
But it is not a “distributed log”. Pulsar (as Kafka) is built on a distributed ledger/log. People confuse ‘semantics’ of messaging with “message broker” so equate various products supporting ‘messaging semantics’.
To your point, and to doubters, simply try building an event sourcing system (complete with replays to recover) on RabbitMQ and see how that works out!
Not "currently" a distributed log, but we're working on adding that (in a Rabbity way). We're not trying to compete with the likes of Pulsar or Kafka though, we're just trying to round out RabbitMQ's functionality to ensure it remains the best swiss army knife of messaging - and log semantics (and performance) is now a dominant paradigm.
You're working on Rabbit team now? Interesting! Ironically enough, you probably have a lot to do with Pulsar gaining mindshare. Thanks for your blog; very informative.
I agree a statement that Pulsar and RabbitMQ are two different products. I understand Pulsar could be missing key based binding, exchanging, and routing in RabbitMQ. (to certain extend, Pulsar Function and key based routing might be able to provide routing features but it is not baked as first class citizen as RabbitMQ.) Do you care to elaborate what are a lot of missing features for event driven from Pulsar?
(Another clarification - Technically Pulsar client is a thick client. It allows both client and broker to co-manage the flow control. It is more than a push based queue. It does data streaming.)
But it is not a “distributed log”. Pulsar (as Kafka) is built on a distributed ledger/log. People confuse ‘semantics’ of messaging with “message broker” so equate various products supporting ‘messaging semantics’.
To your point, and to doubters, simply try building an event sourcing system (complete with replays to recover) on RabbitMQ and see how that works out!