3 ms·

From the perspective of someone like Blow, Rust's concept of safety is like childproofing a house by putting latches on all the cabinets while ignoring the load

From the perspective of someone like Blow, Rust's concept of safety is like childproofing a house by putting latches on all the cabinets while ignoring the loaded gun on the coffee table.

humanrebar 11y ago
I don't follow the analogy. What's Rust's loaded gun?
- 0xcde4c3db 11y ago
  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.
  - pcwalton 11y ago
    > 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.
    - 0xcde4c3db 11y ago
      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.
      - pcwalton 11y ago
        > 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.
        0xcde4c3db 11y ago
        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).
vvanders 11y ago
I used to have similar thoughts. That said having used Rust for ~1 month now I'm much father along the line towards drinking the kool-aid. I've yet to see any deal breakers(custom allocators are coming) and I've not yet crashed once(!) in my entire time using it. Try that with C/C++/ObjC/etc. With functional approaches to polymorphism combined with an ownership model that I really like and I think we could see Rust make some serious in-roads in the next few years.

From the perspective of someone like Blow, Rust's concept of safety is like childproofing a house by putting latches on all the cabinets while ignoring the loaded gun on the coffee table.

humanrebar 11y ago

I don't follow the analogy. What's Rust's loaded gun?

0xcde4c3db 11y ago
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.
- pcwalton 11y ago
  > 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.
  - 0xcde4c3db 11y ago
    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.
    - pcwalton 11y ago
      > 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.
      - 0xcde4c3db 11y ago
        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).

vvanders 11y ago

I used to have similar thoughts. That said having used Rust for ~1 month now I'm much father along the line towards drinking the kool-aid. I've yet to see any deal breakers(custom allocators are coming) and I've not yet crashed once(!) in my entire time using it. Try that with C/C++/ObjC/etc. With functional approaches to polymorphism combined with an ownership model that I really like and I think we could see Rust make some serious in-roads in the next few years.