Danube is an open-source, distributed publish-subscribe (Pub/Sub) message broker system developed in Rust. Danube aims to be a powerful, flexible and scalable messaging solution. Currently, the Danube platform exclusively supports Non-persistent messages. Meaning that the messages reside solely in memory and are promptly distributed to consumers if they are available, utilizing a dispatch mechanism based on subscription types For comprehensive information on setting up, configuring, and using Danube, please refer to the official documentation and the previous article.

Danube is an open-source, distributed publish-subscribe (Pub/Sub) message broker system developed in Rust. Inspired by the Apache Pulsar messaging and streaming platform, Danube incorporates some similar concepts but is designed to carve its own path within the distributed messaging ecosystem. At the time of writing, the Danube platform is in the early stages of development and may have missing or incomplete functionalities. Use with caution. Contributions are welcome, and you can also report any issues you encounter.

Effective error handling ensures that a program can gracefully handle unexpected situations and errors, making the software more robust and reliable. Well-designed error messages help users understand what went wrong and how to correct it, and contribute to the overall user experience using the library or the API. In this article I’ll gradually go through a number of options of handling errors in Rust and try to explain the benefits of using a method vs the other.

The Builder Pattern is a design pattern that provides a way to construct a complex object step by step, focusing on breaking down the construction of the object into smaller, more manageable steps. It separates the construction of a object from its representation, allowing the same construction process to create different variations or representations of the final object. This helps improve code readability, especially when dealing with objects that have a large number of attributes or configurations.

In this article I’m exploring the process of implementing a Fan-Out/ Fan-In pipeline in Go and Rust. Fan-Out is a term to describe the process of starting multiple workers to handle input from the pipeline, and Fan-In is a term to describe the process of combining multiple results into one channel. I’m assuming that you have some familiarity with both Go and Rust languages. I’m new to Rust also, therefore it’s fair to say that this is about concurrency in Go & Rust through the eyes of a GO developer.