I always felt "for embedded" was always selling this crate short, or rather pushing potential users away who aren't aware some data structures here are useful in non-embedded scenarios.

I for example use the admittedly simple Deque (with its is_full()) method in one of my projects for pushing/popping tasks to/from a fixed-size thread queue, which one could argue is a very unembedded-like use-case 😉.

[–] sgued@programming.dev 2 points 1 month ago (2 children)

The limitation of needing compile-time knowledge of the max size of the Deque is pretty rough though.

[–] TehPers@beehaw.org 2 points 1 month ago (1 children)

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.

[–] Vorpal@programming.dev 4 points 1 month ago

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.