3 ms·

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 t

• bblum 14y ago
  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.
  • kaffiene 14y ago
    That comment about GC in graphics sounds like BS to me. Java manages to handle situations like graphics rendering & GC perfectly well. You simply choose a GC that doesn't take large pauses. Graphics isn't an environment where you prove or statically guarantee performance a priori ('statically guarantee') - you run, profile and modify till it works. What's more, certain GCr's can make guarantees about not taking large pauses. p.s.: this is no criticism of Rust - looks very interesting and as a C/C++ programmer, I'll definitely be taking a look at it.