How does this relate to the zmq crate?

[rotty]

Full disclosure: I've started hacking a bit on zmq lately, so I have an agenda ;-).

I wonder how this crate should relate to zmq. My goal is to provide high-level, nearly-idiomatic bindings in zmq, without reducing expressivity compared to the libzmq C API. Both points still need work, obviously.

Given that "mission statement" of zmq, I'm not sure if having C binding to libczmq is the ideal way to achive a "czmq-like" API in Rust. Wouldn't layering it on top of zmq itself be a better solution, both in terms of safety (less tricky C binding unsafe code), and probably also overall effort?

[petehayes102]

I see your point. I started this project because I needed some CZMQ functionality right away (namely crypto/auth) and liked being lazy about sharing contexts. Also rust-zmq had been static for a while and PRs weren't moving, so it made sense to start this project independently.

I think you're right that the binding isn't very "Rusty" and could be improved a lot. I would totally support an effort to take the features of CZMQ and build them into rust-zmq natively. It would also do away with another code dependency, which for me is a win-win!

[petehayes102]

While I think of it, a good place to start might be strongly typed message frames. CZMQ refers to them as picture messages (see https://github.com/zeromq/czmq/blob/master/src/zsock.c#L825). You could even bring in Serde for encoding/decoding... I wanted to do that with this binding but never got around to it.

[rotty]

In a way, zmq already has partial support for that in current master: Socket::send() uses Into<Message> there, so you can make your own types work with it. I plan to provide more high-level support for that based on the tokio stack, which already has a principled approach for encoding/decoding. I've started an zmq-tokio repo, but it's still at the sketchpad-scribbling level.

There's definitly a lot of useful stuff in CZMQ (I must admit I have never used it), but OTOH, a lot of it seems to overlap with what is provided in the Rust standard library or the "native" Rust ecosystem.

Note that the rest of this message is just some pulling some related thoughts off the top of my head.

• I'd like for rust-zmq kind of be "a layer above libzmq, as thin as possible, while adding the maximum amount of type safety, without constraining expressivity"; so adding any specific encoding (like the CZMQ one) would be out of scope for the zmq crate.

• However, we (Rustaceans in general) definitly want a crate that, e.g. implements the "picture message" feature of CZMQ, etc.

• If the consensus at some point is that wrapping CZMQ does not make much sense in the long run, it would still be nice to have a "CZMQ translation guide", offering pointers and explanations for the ideomatic/native ways to do the stuff that CZMQ provides.

Edited for typos

[petehayes102]

Ok, I just Googled "rust tokio" to figure out what that was ;) I'm pretty new to Rust so not going to make arguments for or against that!

Just keep in mind that the whole point of CZMQ was to eliminate much of the common boilerplate C devs were experiencing when implementing ZMQ. There is the same need in any language. The question is simply whether to bind to CZMQ as this lib does, or (time permitting) write a native library that achieves the same goals in a Rusty way.

I'm not sure that a translation guide would be all that helpful, as you haven't eliminated boilerplate, you've just talked about it. 😄