[UtherII]

I not sure he mean never panic at runtime. I think there are good reason to panic at runtime if you care about safety a buffer overflow is a good reason for instance.

But a memory allocation failure is clearly not a good reason.

[OskarS]

It would be hard for him to be clearer:

> With the main point of Rust being safety, there is no way I will ever accept "panic dynamically" (whether due to out-of-memory or due to anything else - I also reacted to the "floating point use causes dynamic panics") as a feature in the Rust model.

[remexre]

WRT floating-point, worth noting for those who haven't read the patches:

- Kernels generally don't want to use floating-point, because saving and restoring the floating-point registers is fairly expensive. - Without some pretty aggressive hacking, it's not possible to remove floating-point support from Rust. - What you /can/ do (and what these patches do) is replace all the floating-point builtins with kernel panics. - This obviously sucks versus actually removing the floating-point, but this is an RFC.

[myrrlyn]

There is some work in progress to make it easier to tell Cargo to build `core`/`alloc`, which in turn would allow projects to maintain patches atop them like disabling floating-point or oom-panicking APIs entirely. I suspect that this effort will get a great deal of motivation from being a kernel requirement

[CodeWriter23]

I think the gist of what he is saying is typical application programming patterns like crash on exception, gc, etc. are not a good fit for kernel programming. And I agree. Handle the request or return an error and let higher level code handle the error processing.

[dnautics]

Out of memory allocation panic is absolutely not acceptable in a kernel, and even less so when you're linux (which does some sneaky memory overcommit things)