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)

@Moore @cliffle I think this is a reasonable point of view, but I don't know if it's correct yet. What do you think about the seL4 approach to resource management?

@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 Another idea is that if you have something like an event loop you can require all functions to be total and then use static analysis to compute the worst case allocation which would be easy if you used a bump allocator in the event loop. (Long lived allocations would need to be moved to statically allocated structures before returning out of the event loop.)

Really the root idea is no computer has infinite memory, so why do we write programs like they do.

@Moore
I think the basic answer to "Why do we write programs like the computer has infinite memory?" is a little complicated.

In what I think you're calling "system programming", we write programs because we know what they will output, and we want them to output it reliably, without failing. For example, firmware for a motor controller. In those cases it is very bad to write programs like the computer has infinite memory, because it means those programs will fail sometimes, and we don't want them to fail.

Other times, though, we write programs because we *don't* know what they will output, and we are running the program to find out. Like, if you already have the output that a compiler will produce in a given case, there's no point in running the compiler on the same input again. In those cases, it's very helpful to be able to pretend that the computer has infinite memory, because usually we have a pretty good plan for what to do if the program fails.

This dichotomy is more glib than the reality, of course, and there are lots of complexities and fuzzinesses, but I think these two general attractors do sort of exist in the real world.

@xentrac my hypothesis is that with advances in programming languages we can get ergonomic programming environments that produce programs that cannot crash outside of hardware faults. You could give them input that is too large to process but that they would always return with an error that explains what would be required to succeed.

@Moore I don't think so, because some problems have small input but require a lot of working memory, and some are by nature incompletely computable.