this post was submitted on 21 Aug 2025
        
      
      35 points (97.3% liked)
      Rust
    7444 readers
  
      
      63 users here now
      Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
        founded 2 years ago
      
      MODERATORS
      
    you are viewing a single comment's thread
view the rest of the comments
    view the rest of the comments
The limitation of needing compile-time knowledge of the max size of the
Dequeis pretty rough though.In this case, it seems like a feature.
It does make me wonder why not use a bounded channel instead (assuming these tasks are shared between threads, maybe because it's multi-consumer?) but a deque is more flexible if that flexibility is needed.
Personally, I can think of a use for this myself. I have a project where I'm queuing audio to play in the background, and using this kind of deque for the queue would work here as well (though I use a bounded channel currently).
There are also a lot of times when i've wanted a stack-only data structure to avoid allocations where these can theoretically come in.
Also worth noting is smallvec and compact_str crates. These are useful when you most of the time have small data that you want inline, but are OK with falling back to heap allocation for the occasional outlier.
I have used both inside structs to optimise cache usage. For these uses i tend to use rather short smallvec.
And smallvec in particular is also useful on the stack in a larger variant in hot functions where you might have a Vec that almost always is less than (say) 32 elements, but the program should gracefully handle the occasional long case. I found this offered a small speed up in some batch data processing code I wrote.