Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RabbitMQ 4.0

github.com

Post reply on HN
Print view View original

11–20 of 120 posts

Re: RabbitMQ 4.0

#11

Post by Joel_Mckay »

nesarkvechnep wrote: post #5
fidotron wrote: post #3

I've regarded RabbitMQ as a secret weapon in plain sight for years. The killer reason people don't use it more is it "doesn't scale" to truly enormous sizes, but for anyone with less than a million users it's great. Too many people end up with their own half rolled pubsub via things like grpc, and they'd be far better off using this, particularly in the early stages of development.

Erlang is a secret weapon.

RabbiMQ also graciously maintains a very nice Erlang repository for Debian.

Reminds me, I'll have to check if they have a working donation link someplace. =3

Re: RabbitMQ 4.0

#12

Post by Zambyte »

packetlost wrote: post #6
leetharris wrote: post #4

Earlier quoted context omitted.

This is how I feel about NATS: https://nats.io/ It's an infinitely more friendly version of Kafka, pub/sub, etc that is extremely lightweight. Yet every environment trends towards Kafka because it was "chosen" by the big corps.

I've used both and NATS is definitely what I'd pick starting out. RabbitMQ is great too, but its heavier and harder to configure. Federation is the killer feature of RabbitMQ that NATS doesn't really have (afaik?).

I've never used RabbitMQ, but NATS supports clustering, super clustering, and leaf node connections. I'm guessing the latter is the closest to what would be considered "federation" in this context.

Edit: spelling

Re: RabbitMQ 4.0

#13

Post by Joel_Mckay »

smetj wrote: post #9
fidotron wrote: post #3

I've regarded RabbitMQ as a secret weapon in plain sight for years. The killer reason people don't use it more is it "doesn't scale" to truly enormous sizes, but for anyone with less than a million users it's great. Too many people end up with their own half rolled pubsub via things like grpc, and they'd be far better off using this, particularly in the early stages of development.

Agreed. I ran a log ingestion infra 8 years ago doing 20k msg/s sustained on RabbitMQ ... back then we went through a lot of instabilities though they settled over time with new releases. Great times. Besides a quality product the development/release process was very professional and mature. The biggest issue back then was finding a quality client implementation for the language you were using. Not sure what the stat…

AMQP and MQTT are both industry standard protocols. Also, RabbitMQ allows you to abuse the limits set by these standards.

Its unfortunate your team ran into performance issues, as Erlang can be inefficient in some situations. Were you using static routes on the DNS load balanced parallel consumers, or relying on the disk caching mechanisms?

Re: RabbitMQ 4.0

#14

Post by hyperadvanced »

shandor wrote: post #7
leetharris wrote: post #4

Earlier quoted context omitted.

This is how I feel about NATS: https://nats.io/ It's an infinitely more friendly version of Kafka, pub/sub, etc that is extremely lightweight. Yet every environment trends towards Kafka because it was "chosen" by the big corps.

So how about NATS compared to RabbitMQ? If building from scratch, what would drive a design or team towards NATS?

Have used both extensively:

NATS, especially in its most elementary form, is braindead simple, stateless, and ootb functional. If I only want a message broker/pubsub, I pick that. If I know on day 1 that I need queues or persistence, I would probably pick Rabbit over NATS’ offering (Jetstream).

Re: RabbitMQ 4.0

#15

Post by latenightcoding »

fidotron wrote: post #3

I've regarded RabbitMQ as a secret weapon in plain sight for years. The killer reason people don't use it more is it "doesn't scale" to truly enormous sizes, but for anyone with less than a million users it's great. Too many people end up with their own half rolled pubsub via things like grpc, and they'd be far better off using this, particularly in the early stages of development.

It isn't more popular because it's not easy to use it properly.

I haven't touched it in years so I can't expand, but when I did, I had to write so many wrappers and add extra logic to use it properly.

Re: RabbitMQ 4.0

#16

Post by atmosx »

shandor wrote: post #7
leetharris wrote: post #4

Earlier quoted context omitted.

This is how I feel about NATS: https://nats.io/ It's an infinitely more friendly version of Kafka, pub/sub, etc that is extremely lightweight. Yet every environment trends towards Kafka because it was "chosen" by the big corps.

So how about NATS compared to RabbitMQ? If building from scratch, what would drive a design or team towards NATS?

RabbitMQ shines when you need complex queue routing based on keys or headers. Instead of baking the logic to the app you can offload the routing logic to rabbitMQ. Same is true for NATS and Kafka.

I must say that rmq in k8s, is possible but hard to admin. It’s not a “toy”. But has great documentation. Will take several iterations to key in the right configuration for the use case.

NATS and Kafka can handle higher volumes on the same resources but IMO the use cases are different or you have to write lots of code app side to implement what rmq does with these tools.

Re: RabbitMQ 4.0

#18

Post by heipei »

fidotron wrote: post #3

I've regarded RabbitMQ as a secret weapon in plain sight for years. The killer reason people don't use it more is it "doesn't scale" to truly enormous sizes, but for anyone with less than a million users it's great. Too many people end up with their own half rolled pubsub via things like grpc, and they'd be far better off using this, particularly in the early stages of development.

I could say the same thing about NSQ which is a distributed message queue with very simple semantics and a great HTTP API for message publishing and control actions. What it doesn't offer natively is HA though.

Re: RabbitMQ 4.0

#19

Post by Jenk »

I lost a lot of respect for the RabbitMQ maintainers when they refused to honor the semantic versioning scheme in package managers like nuget/maven/etc. "Safely upgrading" was impossible. 3.5 => 3.6 saw the removal of an argument.

They didn't lose my respect for the removal of the argument, however, they lost my respect for whatabouting the conversation calling SemVer a "no true scotsman" fallacy, then trying to claim that removing a redundant argument is not a breaking change, and other reality-warping nonsense, before blocking myself and other complainants from their issues - and even deleting some of their own comments to mop up some of their own terrible reasoning.

I'm sure there is no love lost on their side, either. Personal rant over.

Re: RabbitMQ 4.0

#20

Post by ehsanu1 »

hyperadvanced wrote: post #14
shandor wrote: post #7

Earlier quoted context omitted.

So how about NATS compared to RabbitMQ? If building from scratch, what would drive a design or team towards NATS?

Have used both extensively: NATS, especially in its most elementary form, is braindead simple, stateless, and ootb functional. If I only want a message broker/pubsub, I pick that. If I know on day 1 that I need queues or persistence, I would probably pick Rabbit over NATS’ offering (Jetstream).

What does Jetstream lack wrt queues/persistence?
Post reply on HN