4 ms·

It has a gorgeous landing page but I'm not really sure why this is better than any other MQ. Can someone more knowledgeable provide any insight into its compara

by hkt 3y ago

It has a gorgeous landing page but I'm not really sure why this is better than any other MQ. Can someone more knowledgeable provide any insight into its comparative advantages? Edit: I did see the comparisons page, but.. well, there's more to life than Rabbit and Kafka!

traceroute66 3y ago
> Can someone more knowledgeable provide any insight into its comparative advantages? Well, you know, there is the "Comparison With Alternative Systems" page[1]. :-) Sadly it doesn't include NATS in the comparison. I would have been interested to see that. But the usual suspects (Rabbit & Kafka) are given a mention. [1] https://bloomberg.github.io/blazingmq/docs/introduction/comparison/ https://bloomberg.github.io/blazingmq/docs/introduction/comp...
- rlonstein 3y ago
  I'd also be interested in seeing how it compares to AMQP implementations (Apache Qpid for example) and any of the proprietary message queue systems (IBM and Microsoft) they refer to but don't name-check.
vyskocilm 3y ago
FJI: There is a faq entry about that https://bloomberg.github.io/blazingmq/docs/introduction/comparison/ https://bloomberg.github.io/blazingmq/docs/introduction/comp...
Cthulhu_ 3y ago
I mean one unsubstantiated armchair take: it's newer than Rabbit / Kafka (RabbitMQ was built in 2007, Kafka in 2011), since then the learnings from distributed systems, message queues and programming languages has improved by leaps and bounds, and the existing ones will have backwards compatibility / legacy issues. That said, there are indeed plenty of commercial and noncommercial alternatives, so now that it's been published I'm sure there will be some thorough people making comparisons soon!
MathMonkeyMan 3y ago
My guess is that at the time when Bloomberg's infrastructure was considering supporting a message queue, they surveyed existing solutions (mind you that this was a long time ago) and found them lacking for one reason or another, rightfully or not. RabbitMQ was probably avoided because nobody wanted to learn Erlang. Also, R&D had a lot of experience building message oriented middleware "from scratch" in a low overhead high availability way, so first instinct was probably to start hacking in C++. Nowadays it might be the case that some teams within Bloomberg need the performance or would rather have a bespoke solution instead of spending on migrating to something else off the shelf. Keep in mind that this is a company that has its own implementation of most of the C++ standard library.

by hkt 3y ago

traceroute66 3y ago

> Can someone more knowledgeable provide any insight into its comparative advantages? Well, you know, there is the "Comparison With Alternative Systems" page[1]. :-) Sadly it doesn't include NATS in the comparison. I would have been interested to see that. But the usual suspects (Rabbit & Kafka) are given a mention. [1] https://bloomberg.github.io/blazingmq/docs/introduction/comparison/ https://bloomberg.github.io/blazingmq/docs/introduction/comp...

rlonstein 3y ago
I'd also be interested in seeing how it compares to AMQP implementations (Apache Qpid for example) and any of the proprietary message queue systems (IBM and Microsoft) they refer to but don't name-check.

vyskocilm 3y ago

FJI: There is a faq entry about that https://bloomberg.github.io/blazingmq/docs/introduction/comparison/ https://bloomberg.github.io/blazingmq/docs/introduction/comp...

Cthulhu_ 3y ago

I mean one unsubstantiated armchair take: it's newer than Rabbit / Kafka (RabbitMQ was built in 2007, Kafka in 2011), since then the learnings from distributed systems, message queues and programming languages has improved by leaps and bounds, and the existing ones will have backwards compatibility / legacy issues. That said, there are indeed plenty of commercial and noncommercial alternatives, so now that it's been published I'm sure there will be some thorough people making comparisons soon!

MathMonkeyMan 3y ago

My guess is that at the time when Bloomberg's infrastructure was considering supporting a message queue, they surveyed existing solutions (mind you that this was a long time ago) and found them lacking for one reason or another, rightfully or not. RabbitMQ was probably avoided because nobody wanted to learn Erlang. Also, R&D had a lot of experience building message oriented middleware "from scratch" in a low overhead high availability way, so first instinct was probably to start hacking in C++. Nowadays it might be the case that some teams within Bloomberg need the performance or would rather have a bespoke solution instead of spending on migrating to something else off the shelf. Keep in mind that this is a company that has its own implementation of most of the C++ standard library.