We have a crate internally that uses type-level programming to do statically tracked memory allocation (technically the method can be used for other kinds of re

We have a crate internally that uses type-level programming to do statically tracked memory allocation (technically the method can be used for other kinds of resource management too), so that we can have compile-time guarantees that allocations will always succeed and we'll never allow memory to be allocated from inappropriate regions (e.g. mapped registers). Layered on top of that we can also ensure that if at runtime your device memory configuration is sufficiently different from what your assumptions were at compile-time, then we don't allow the device to boot so that you don't end up in a dangerous resource exhaustion situation by accident. We use this for no_std embedded shaped use cases, but you could also use this library and programming model to create a special heap in your normal programs which have statically tracked allocations to create some region of your program context that you want to have assurances like that. We have 3-4 things kind of in that vein in our pipeline to open source, and I think that's number 3.