6 ms·

Fair enough. I'm sorry about calling you out on the metaphor. Instead I'll call you out on the point itself :-) > Having safety features that you know you ca

• rcthompson 10y ago
  I think it's more like: since you know the compiler won't let you write a buffer overflow, use-after-free, data race, etc., you no longer have to waste time worrying about whether your code might contain such problems, which frees up more mental bandwidth for other concerns. But unlike other languages, you still have confidence that your code will compile to equally performant machine code (e.g. No GC overhead). The scary thing isn't causing a segfault on your local machine. The scary thing is writing code that could segfault but doesn't do in testing until after you've deployed it publicly. If your compiler rejects code that can segfault, this is no longer a concern. (Or replace segfault with a buffer overflow that leaks your private keys or something equally bad.) I guess the analogy would be that you can have more fun cavorting across the sky if you knew with 100% confidence that your parachute automatically would deploy itself at the appropriate time (and not a moment sooner).
  • zerofan 10y ago
    > I think it's more like: since you know the compiler won't let you write a buffer overflow, use-after-free, data race, etc., you no longer have to waste time worrying about whether your code might contain such problems, which frees up more mental bandwidth for other concerns. I've spent a lot of time figuring out how to do completely mundane things in Rust. At this point, buffer overflows and use-after-frees are not my biggest concerns in C++. > The scary thing isn't causing a segfault on your local machine. The scary thing is writing code that could segfault but doesn't do in testing until after you've deployed it publicly. If your compiler rejects code that can segfault, this is no longer a concern. If your testing didn't catch the problem (which I can fully understand), a panic at runtime is not much different than a segfault. > (Or replace segfault with a buffer overflow that leaks your private keys or something equally bad.) I firmly believe the OpenSLL team would've used unsafe blocks in Rust to disable the performance overhead of bounds checking. That whole exploit was caused by sloppy optimizations, and Rust is not immune from that.
    • kbenson 10y ago
      > I've spent a lot of time figuring out how to do completely mundane things in Rust. At this point, buffer overflows and use-after-frees are not my biggest concerns in C++. I could visit a country with a completely different set of laws regarding driving and a different road marking system. After a few days of driving, I might also feel like I've spent a lot of time trying to figure out how to navigate the rules of the road rather than actually getting to my destination when compared to driving in my native lang. I would also be unable to accurately ascertain whether one system was better than the other, because of inadequate experience with the new system. It would be a mistake to assume that I could become proficient enough in such a complex system in such a short period of time as to ascertain whether one was better than the other. To put it another way, I don't feel like avoiding bicyclists is my biggest problem when driving, but having a dedicated bike lane at all times would probably be a good idea anyways. Sure, maybe you've never hit a cyclist, and never will. That doesn't mean it doesn't happen enough that we shouldn't do something about it, because it does. > If your testing didn't catch the problem (which I can fully understand), a panic at runtime is not much different than a segfault. No, a segfault at runtime is something that is possibly exploitable. A Panic is not. > I firmly believe the OpenSLL team would've used unsafe blocks in Rust to disable the performance overhead of bounds checking. Even if they did, that would still reduce the portion of the code that needs to be audited to those blocks. Effort could be made to reduce the size and scope of those blocks. There is something to be said for having the ability to categorize and enforce different safety levels in your codebase, when the alternative is no categorization or enforcement.
      • zerofan 10y ago
        > I could visit a country with a completely different set of laws regarding driving [...] Arguments by metaphor aren't my thing. It's very likely I would become more proficient at Rust if I programmed in it more. It's also very likely the poster above would worry less about memory errors if s/he programmed in C or C++ more. Yes, Rust is safer in some ways, but I still can't understand where all the fear of other languages comes from. > having a dedicated bike lane at all times would probably be a good idea anyways. I used to live in a city with a lot of dedicated bike lanes. I commuted to work on a particularly long stretch that was very popular for cycling. The majority of the cyclists refused to ride in the lane. It turns out that cars naturally blow the dust and small pebbles out of the main road way, but bikes don't do that in the bike lane. Cars also smooth out the pavement in their tire tracks. The result was a road that's 5 foot narrower for cars (speed limit 45 mph) with bicyclists in it (not moving 45 mph), a generally unused bike lane, lots of uncomfortable passing, and a lot of indignation from cyclists who claimed an equal right of way despite having a separate lane designated for them. > Sure, maybe you've never hit a cyclist, and never will. That doesn't mean it doesn't happen enough that we shouldn't do something about it, because it does. The city I live in now has many bike paths, completely separate from major roads. It's also a different climate, so there are less pebbles and they have street sweepers clean the road after snow season to remove the sand. There really doesn't seem to be much interaction between the cyclists and the cars. So should I choose a programming language with bike lanes on major roads or separate paths though the parkways? :-) > No, a segfault at runtime is something that is possibly exploitable. A Panic is not. Anything is possible, but it's very unlikely. I will write a program and intentionally put a buffer overflow in it. Can you send me some data that will exploit it? Here's a metaphor that also isn't one: I'm not afraid of terrorists despite some high profile events in the last 20 years. I certainly wouldn't optimize my life around avoiding terrorist attacks because the empirical evidence shows me the probability is very low.
• rcthompson 10y ago
  Perhaps a better analogy would be the way that much of modern medicine is enabled by access to antibiotics. Without antibiotics, the risk of post-operation death by infection would be so high as to rule out many of the procedures that we now consider safe and routine.
  • zerofan 10y ago
    I would prefer a surgeon who washed his hands over one who didn't but gave me antibiotics. I've had stitches a few times, but only one real surgery. I never got antibiotics for any of those. Maybe we could skip the analogies? I don't think they help the discussion.
    • jibalt 10y ago
      They help in a discussion with someone intellectually honest.