emqx VS mop

EMQX (optional): Open-source MQTT broker for IoT, IIoT, and connected vehicles. Used for managing your toys.

I do know a real world use for Erlang (it also surprised me when i investigated about it), but two of the biggest mqtt brokers are coded in erlang: emqx, vernemq

EMQX is a 10-year-old open-source project under Apache License 2.0, with 11k stars on GitHub（https://github.com/emqx/emqx), 20M downloads on DockerHub (https://hub.docker.com/r/emqx/emqx), and 400+ paid customers worldwide. The Sweden address you mentioned is only the registered address of our Sweden entity. We’re a globally distributed team. EMQX European R&D team members work remotely in Sweden, Germany, the UK, and Brazil. We have similar registered addresses for entities in Germany and the USA too. See my response in linkedin for the address doxing.

Hello, we’ve met situations where messages are accumulated in EMQX due to slow user consumption, and then EMQX will be killed by the operating system as it takes up too much memory. It is usually caused by improper configuration. However, we are unclear about what kind of situations you met. Could you please raise an issue in our GitHub community at: https://github.com/emqx/emqx/issues? Our experts will try to offer help asap.

EMQX is an open-source, highly scalable, and distributed MQTT messaging broker written in Erlang/OTP that can support millions of concurrent clients. As such, there is a need to persist and replicate various data among the cluster nodes. For example: MQTT topics and their subscribers, routing information, ACL rules, various configurations, and many more. Since its beginning, EMQX has used Mnesia as the database backend for such needs.

EMQX(https://github.com/emqx/emqx) is an open-source project under Apache License 2.0, we don't think there are national borders for open source. The nature of its being open-source means it is developed, tested, and used by the open-source community worldwide. For a popular open-source project that has been downloaded by 15M times and adopted so widely globally for many years, it’s impossible to have a backdoor hidden without being discovered.

While Pulsar has its own protocol that handles streaming, queues, and a lot of the other features (distributed transactions, functions, etc.), it can also speak other messaging protocols via plug-ins. Looking around, the ones that appear to be actively developed are MQTT, Kafka (so your existing applications that use Kafka can also use Pulsar), AMQP, and JMS.

If you need a highly available broker you can consider https://github.com/streamnative/mop which adds a MQTT protocol handler to Apache Pulsar.

I recently contributed auth support and TLS support also just landed.