I wondered how long it would take for somebody to call me out for that. It seemed like a sketchy claim when I wrote it (it wouldn't be too complicated to make the @-heap lock-free in rust, for starters), but in retrospect, I shouldn't have said it at all. Thanks for pointing that out.
I tried to think of an alternate justification, but couldn't come up with a non-awkward way of saying it, so just redacted that part entirely. I'll say here, though, a few reasons I think avoiding malloc/GC is important:
- pcwalton has mentioned his desire to be able to reason about when the garbage collector runs, so that he can statically guarantee that the graphics rendering task in servo will never take a big pause to do a GC.
- In this-must-never-fail environments, such as writing kernel device drivers, using dynamic allocation has to be avoided (and, if i'm not mistaken, even more likely to fail when done in an "atomic section" using kmalloc(GFP_ATOMIC)). Rust in its current state is not suitable for kernel-level development, but it's not far off; and it's critical to be able to reason about memory allocation for such applications.
