11 ms·

> The two languages, ecosystems, and communities seem to have largely non-overlapping objectives despite having overlapping technical capabilities. I keep thin

> The two languages, ecosystems, and communities seem to have largely non-overlapping objectives despite having overlapping technical capabilities. I keep thinking servers should be written a bit more like embedded thingies. (Though I suspect the actual trend is in the other direction). Both kinds of software deeply interested an asynchrony and concurrency (though not necessarily parallelism). And both also tend to talk over networks to other gadgets as part of a complex system. And since my job often revolves around putting out fires when severs OOM, I'd also like to see a lot less malloc(). It would be nice if software could place hard upper limits on how many resources (including RAM) it takes to serve a request and then reject requests early. With real-world languages and frameworks, we can only do very primitive approximations to this. But a framework written from the bottom-up with a malloc-is-evil mentality () might be able to do it.

swsieber 7y ago
hmm... there are many libraries that are no-alloc. It seems quite feasible (well, that and custom allocators are a thing now)..
im_down_w_otp 7y ago
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.

swsieber 7y ago

hmm... there are many libraries that are no-alloc. It seems quite feasible (well, that and custom allocators are a thing now)..

im_down_w_otp 7y ago

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.