Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

although it never really sacrifices any control.

It feels like it sacrifices control wrt when you allocate and free-memory.

I understand it's deterministic in rust, but it's not explicitly controllable - or at least I've seen it be.



You have to bring your own memory in no-std. Implicit alloc is provided by the alloc crate (part of std).


Rust is a manual memory managed language, it literally has nothing inexpressible that C could do. Hell, C is a “higher level” language in that it doesn’t have any way for SIMD instructions.

To add something concrete, you can manually free memory as well based on some dynamic property if you wish.


I don’t follow. It’s exactly like C in this regard, except with Box::new instead of malloc.


The key difference as outlined in the article is that Box::new cannot fail in Rust, but the underlying malloc can.

In userspace it is rare enough that a Rust panic is considered acceptable behavior, but this is not the case for the kernel.

But, it is controllable for sure


Unsurprisingly the kernel's Box does not have Box::new it provides instead Box::try_new which is fallible.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: