3 ms·
Struggling to see when I'd use this over, say, rabbitmq. Feels a bit like "not invented here" syndrome, though glad to be proven wrong. Also curious that this r
by foo42 11y ago
Struggling to see when I'd use this over, say, rabbitmq. Feels a bit like "not invented here" syndrome, though glad to be proven wrong. Also curious that this replaces previous tooling written in erlang, be interested to here what prompted the move to golang, I would think a message broker was right in erlang's wheelhouse
- lobster_johnson 11y agoNot the OP, but this looks like it's designed to be lossy, and prioritize availability over deliverability. If clients are unable to keep up with message volume, messages will be dropped. That makes is okay for things like realtime dashboards (which this is apparently designed for) and other rapid events where transactionality is not required. But it's obviously not suited for job-like scheduling like data processing or email delivery. Nor as an event bus for inter-service coordination ("on event X, do Y").
- tylerflint 11y agoThat's a pretty accurate assessment. Mist could be conceptualized as a self-hosted replacement for pusher (https://pusher.com/ https://pusher.com/). It's designed specifically to address building realtime web apps.
- deleted 11y ago[deleted]
- tylerflint 11y agoEverything that mist does is "right in erlang's wheelhouse". Erlang is awesome and the actual reason we moved golang had nothing to do with erlang vs golang. I responded to that in detail at another spot on this thread (currently above, but who knows if that is still the case).