|
|
|
|
|
by tialaramex
1055 days ago
|
|
> clanky bits that make it a poor fit for embedded devices. What do you see as "clanky bits that make it a poor fit" for such a broad range of stuff as "embedded devices" ? Embedded goes at least as far as from "It's actually just a Linux box" which is obviously well suited to Rust, to devices too small to justify any "high level language" where even C doesn't really fit comfortably. Rust specifically has no ambitions for hardware too small to need 16-bit addresses, but much of that range seems very do-able to me. |
|
There are lots of systems where memory changes hands. Game programming, for example. You allocate a big chunk of memory, you put some stuff in it, you hand it off to the graphics card, and some amount of time later the graphics card hands it back to you.
Rust gets VERY cranky about this. You wind up writing a lot of unsafe code that is very difficult to make jibe with the expectations of the Rust compiler. It's, in fact, MUCH harder than writing straight C.
Example clanky bit: slab allocation
You often don't really care about deallocation of objects in slabs in video games because everything gets wiped on every frame. You'd rather just keep pushing forward since you know the whole block gets wiped 16 milliseconds from now. Avoiding drop semantics takes (generaly unsafe) code and work.