It's not Rust's loaded gun, which is sort of the problem. Basically, I'm talking about the sorts of relatively low-level APIs whose use is somewhat obligatory for Getting Stuff Done in a performant way, and for which higher-level interfaces typically deny sufficient control and/or hurt performance by heavily wrapping (and often quietly copying/rearranging) the critical data structures and operations. Things like ioctl() calls, OpenGL/DirectX, and so on. Misusing these (or just encountering bugs in them) can pretty easily trash your application -- and sometimes even your kernel -- in really messy ways.
> Basically, I'm talking about the sorts of relatively low-level APIs whose use is somewhat obligatory for Getting Stuff Done in a performant way, and for which higher-level interfaces typically deny sufficient control and/or hurt performance by heavily wrapping (and often quietly copying/rearranging) the critical data structures and operations. Things like ioctl() calls, OpenGL/DirectX, and so on. Misusing these (or just encountering bugs in them) can pretty easily trash your application -- and sometimes even your kernel -- in really messy ways.
OK, but that's why glium is so popular (quite possibly the preferred OpenGL binding in the community nowadays?), which has very low overhead while maintaining OpenGL safety.
ioctls have similar wrappers for the important ones.
glium seems pretty cool (arguably still immature, but certainly not the joke of some wrappers I've seen where the examples/ directory just has adaptations of NeHe 1-5 or so, and anything else requires fiddling with the GL entry points yourself), but I'm not convinced that it's possible to both have low overhead and effectively enforce safety for something like OpenGL. Maybe tomaka will prove me wrong, but I suspect that the worst problems are in the DX/GL/driver stack.
Anyway, the general principle I'm trying to get at here is that when you're in a field that requires specialized expertise beyond general-purpose programming, the domain problems tend to get much, much bigger than the problems posed by generic "unsafe" operations. It's sort of an Amdahl's Law thing. Even a language that gets (lack of) pointers and array bounds checking and the like 100% correct can only possibly save 5% of your hair from being pulled out.
> Even a language that gets (lack of) pointers and array bounds checking and the like 100% correct can only possibly save 5% of your hair from being pulled out.
That's not my experience, and I work in a very specialized domain (at the moment, OpenGL, in fact). It doesn't eliminate all the bugs, but memory safety saves me a lot of time.
Sure; I don't mean to deny that such workloads exist. I was a bit sloppy with my writing; I meant for that sentence to illustrate by describing the situation around the product I work on (which isn't OpenGL-oriented, but does involve a lot of things happening in third-party kernel code and other address spaces).
