lavinmq

Hi HN. I'm Carl, creator of LavinMQ. LavinMQ is an open-source message broker. AMQP 0-9-1, MQTT, HTTP and streaming. Single binary, minimal resource use. If you know RabbitMQ, it's that (but running on a fraction of hardware). We're the team behind CloudAMQP where we've hosted RabbitMQ for 14 years. Sometimes customers hit issues we couldn't fully explain / work around. So we built our own broker, in order to provide solutions where we previously couldn't (which is much easier when you control the full stack). It all started by me building an open-source AMQP proxy to handle short-lived connections for a customer, to avoid heavy connection churn on cpu. Once the protocol was implemented, adding a persistence layer seemed like a fun challenge. How hard could it be? Turns out the protocol was the easy part. Reliable disk storage, ack handl

it seems many big web projects (rails, django, etc. GIL langs) chose go(lang) to write "services" that could be separated. Yet, just about any language with quick execution, quick startup(?), concurrency (and/or parallelism), and a garbage-collecter would work: lisps, ocaml, haxe, nim, crystal, CLI langs (now /w AOT), JVM langs! I wonder what HN folks used. Was it a good choice? i was specifically thinking about crystal for rails, as i noticed a few interesting repos: mosquito, a job scheduler; fruit-juice, a ruby gem to enqueue jobs into mosquito (especially from rails); and lavinMQ, a successor of rabbitMQ(?). https://github.com/mosquito-cr/mosquito | https://github.com/crimson-knight/fruit_juice | https://github.com/cloudamqp/lavinmq/

oh, interesting, so it can be a kafka replacement: https://github.com/cloudamqp/lavinmq/tree/v1.2.10#stream-que... (it's Apache 2)