Using TLS in Rust: tokio Ain't for Mere Mortals
Tokio ain't just for mere mortals.
Join the DZone community and get the full member experience.Join For Free
I kept going with tokio for a while; I even got something that I think would eventually work. The whole concept is around streams, so I created a way to generate them. This is basically taking this code and making it async.
I gave up well into the second hour. Here is where I stopped:
I gave up when I realized that the reader I’m using (which is SslStream) didn’t seem to have poll_read. The way I’m reading the code, it is supposed to, but I just threw up my hands in disgust this time. If it is this hard, it ain’t going to happen.
I wrote a significant amount of async code in C# at the time when events and callbacks were the only option and then when the TPL and
ContinueWith was the way to go. That was hard, and async/await is a welcome relief, but the level of frustration and “is this wrong, or am I really this stupid?” that I got midway through is far too much.
Note that this isn’t even about Rust. A number of issues that I ran into were because of Rust, but the major issue that I had here is that I was trying to write a function that can be expressed in a sync manner in less than 15 lines of code and took me about 10 minutes to write the first time. And after spending more hours than I’m comfortable admitting, I couldn’t get it to work. The programming model you have here, even if everything did work, means that you have to either decompose your behavior to streams and interact with them in this manner or you put everything as nested lambdas.
Either option doesn’t make for a nice model to work with. I believe that there is another async I/O model for Rust, the MIO crate, which is based on the event loop model. I’ve already implemented that in C, so that might be a more natural way to do things.
Published at DZone with permission of Oren Eini, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.