26 ms·
Well, this has already paid off for me, even though I thought I knew most of it. I recently built a toy chat app with tungstenite+websockets, and am now kind of
by wging 4y ago
Well, this has already paid off for me, even though I thought I knew most of it. I recently built a toy chat app with tungstenite+websockets, and am now kind of kicking myself because I could probably have just used axum. At least I got some good practice and learned a couple things by doing it a more 'manual' way, and get to compare it to axum's websocket support.
Something else I'd like to see is a tad more clarity on how the recommended channel implementations relate to std::mpsc::channel and tokio::mpsc::channel - the recommended options seem to claim to be better than their respective std/tokio counterparts, but blessed.rs itself doesn't explicitly make that claim. Should it? (I've only ever used std::mpsc and tokio::mpsc, and not in a production context.)
- necubi 4y agoCrossbeam channels are better in just about every way than std::sync::mpsc. They're faster, have more features (including supporting multiple consumers), and have a better API. Tokio vs crossbeam/std::sync is a bit of a different question. Using the tokio implementations let you await (i.e., asynchronously block) on a channel, whereas the others will block the thread. So within async code, use tokio for use cases where you may have a blocking operation (writing to a bounded queue or waiting for a message). Otherwise, use crossbeam.
- wging 4y agoI didn't mean to imply these were all substitutes for each other - rather that there are both sync and async channels in the list and it seems worthwhile to compare the sync ones against std::sync::mpsc, and the async ones against tokio::sync::mpsc. Not to mention the sync/async ones against each other (flume and postage both have async capabilities). I do think the site does a decent job of calling out that there is a difference between the two types of channel.