RE: https://social.rust-lang.org/@rust/117605013073050966
I'm not sure whether I'm more excited about the stable never type, or DropGuard in std.
Which is a reminder that I'm kind of strange, since the word "allocator" didn't appear in that sentence. 🤪
@cliffle allocators are runtime type checking and we would be better off without them. (In system programming)
@xentrac I have not worked with it but have been following it. It looks interesting.
@Moore I haven't tried installing seL4 either, but I mean, what do you think about its approach to resource management, in the abstract?
@xentrac I don't know enough to have an option but it looks interesting. The time accounting is interesting.
@Moore An interesting thing about that is that they only enable the time accounting for "mixed-criticality systems", where you're relying on the kernel to prevent your Linux virtual machine or whatever from causing glitches in your motor control waveforms or 802.11 acks.
But the main interesting thing about the kernel in this context is that it doesn't allocate memory at runtime. There's no heap.
@Moore How do you envision statically checked memory management working? Are you satisfied with Rust?
@xentrac the easiest way is to statically allocate everything but that can lead to more allocations then strictly necessary if there are two allocations that never overlap in use.
Another idea is to have an allocator as an explicit argument and add capacity to the type of the allocator and an API like:
let (value, allocator) = Box::new(allocator);
This way it would be a type error to over commit.
@xentrac yes