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).
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.