zenoh VS areg-sdk

I'm very new to Rust and currently I'm trying to make sense of async programming in Rust. In my project I'm trying to create an http + websocket server (I picked Actix) that communicates to a CPP program over DDS and sends the result of this communication to some frontend over http/ws. I use Zenoh for leveraging communication between my Rust app and CPP, and it has it's own crate for creating a zenoh client in Rust. In the documentation they use async-std macros for the main function and Actix uses Tokio under the hood, as far as I understand. Is this gonna be a problem? Can I have several async runtimes in my project?

Zenoh's plugin system was one of the main motivators for building stabby. However, Zenoh needs me on other fronts at the moment, so stabby will have to go to the back burner for a bit. This doesn't mean stabby will become unsupported: if you want to use it, and are having a hard time, feel free to DM me to get some support. In fact, what stabby needs most right now is feedback on what types you'd like to see supported, so go for it!

Hello u/ComeGateMeBro, in zenoh we have zero-copy support, this is an example that shows how to use it: https://github.com/eclipse-zenoh/zenoh/blob/master/examples/examples/z_pub_shm.rs

The next step would be to use the zenoh crate, which will simplify a lot of things.

The new Eclipse Zenoh 0.7.0 release, codename Charmander, brings to the table many features requested by the community on the Zenoh’s Discord server.

The Rust code is hosted here: https://github.com/eclipse-zenoh/zenoh While the Rust docs is hosted here: https://docs.rs/zenoh/0.7.0-rc/zenoh/ It's available on crates.io: https://crates.io/crates/zenoh

FP Libraries: gRPC, ZeroMQ, and AREG are examples of libraries with a special focus on providing possibilities for Interprocess Communication. Developed using C++, they facilitate communication through predefined APIs, emphasizing functional programming concepts.

In addition, if the owners of the repositories add more relevant and precise labels to the issues, it increases the possibility that the OSS developers find the issues they would loved to resolve. For example, the issues of AREG SDK which marked "help wanted" in addition have such labels like "C++" or "cmake", "unit test", etc.

My closer introduction with these 2 tools started from OSS areg sdk project. Because of some experienced friend recommendation, i started with make. The main reason was that it is more spread in embedded. No other weighty argument they had. After having make, i decided to integrate cmake. Suddenly i figured out that cmake for me is more understandable and powerful. It already has many features that makes things easier. The biggest advantage for me is that in comparison to make / Makefile, lot of IDE support build with cmake. The cross-platform / cross-compile for areg-sdk is important feature, and this is easier to achieve with cmake. For example, I can compile with make under Linux with gcc/clang, but under windows can compile in cygwin environment and not with MSVC, which is not the issue in case of cmake.

Project: AREG is a cross-platform interface-centric lightweight communication engine, which forms a grid of services in the IoT fog- and mist-network, automates the real-time transmission of data between multiple connected software nodes, so that the connected Things interact like a thin distributed servers and clients. Technologies: C/C++17, standard library dependencies, POSIX and Win32 API. Can be used in real product.

Nice. I also have own project, but it already requires much time, so that cannot join in other projects. As well, up to now have no dependencies, except standard system libraries. I think, we should have a separate post to share projects and give short description. Some might be interested to join.

Here I've crated a list of API that use in the project. Some of methods are part of ncurses.h. So I have a questions: