9 ms·

> I am even more frustrated with the moral crusaders from languages like Rust, one of whom went as far as to suggest that I should personally be criminally pro

• throwaway82652 5y ago
  That comment is definitely out of line and trolling, but the author's attitude towards safety and security is still incredibly bad. Two wrongs don't make a right. I'm dismayed to see more new languages copying the safety and security features of C (i.e. nothing).
  • mplanchard 5y ago
    I think “incredibly bad” is overstating things quite a bit. Safety isn’t an all-or-nothing game. If it were, Rust would be useless because it’s not Ada or another formally verifiable language.
  • ddevault 5y ago
    Hare has significantly more safety and security features than C. Bounds-checked slices, no uninitialized data, mandatory error handling, nullable pointer types, and others still. What it lacks that Rust users object to is a borrow checker.
    • CJefferson 5y ago
      You don't need a borrow checker -- there are many ways to avoid use-after-free bugs. They don't in Java, or Haskell, or Python, to name 3 languages I work in sometimes. However, I really do think for a new "systems language" nowadays, you do want to look at how major security holes occur in practice, and have a good story on how users should avoid them.
      • ddevault 5y ago
        We do take security pretty seriously with Hare. To quote our crypto module's introduction as an example: > Cryptography is a difficult, high-risk domain of programming. The life and well-being of your users may depend on your ability to implement cryptographic applications with due care. Please carefully read all of the documentation, double-check your work, and seek second opinions and independent review of your code. Our documentation and API design aims to prevent easy mistakes from being made, but it is no substitute for a good background in applied cryptography. We have many safety features built into the language and the standard library is designed to be difficult to use incorrectly. I will address these concerns directly in a subsequent blog post covering the safety and security features of Hare. The main problem is that some programmers view anything less than what Rust provides as morally unjustified.
        • Gwypaas 5y ago
          Because rust inherently treats humans as fallible to a large extent. Which all of us are. That introduction is simply an appeal to "I can write safe correct C." with more words. Which obviously is not true.
          • ddevault 5y ago
            I can assure you that Hare takes security more seriously than assuming the programmer is smart enough to do it right. I don't appreciate shallow takes which make unsympathetic judgements on the language which are not based in any understanding of how Hare actually works, and I've heard nothing but such takes for a week.
            • Filligree 5y ago
              How does Hare prevent use-after-free, then? I'd welcome an explanation.
              • ddevault 5y ago
                Hare does not prevent use-after-free, but it does prevent many other kinds of bugs which are common in C. I will go into greater detail in another blog post.
    • throwaway82652 5y ago
      You should be implementing a borrow checker or something like it. It's irresponsible not to do that. I'm serious about this. We know how to totally stop most use-after-free bugs during static analysis now, this is a tool that can be implemented in any language, so people should just do it. If you ask me the status quo moved a long time ago. This has nothing to do with Rust. Also I was wrong before and you were out of line. Matthew wasn't trolling, he never said you should be held criminally liable. You just made that criminal part up for no reason. Anyone should be held socially liable and shamed if their project has bad security and they refuse to fix it after they knew about it. I think you would even agree with that.
• brainwipe 5y ago
  I felt that statement, along with some of the language used in the blog is at odds with the author's goal to... > Part of our work in developing Hare is laying the groundwork for a collaborative, productive, healthy community that people want to work in The goal to have a healthy community is laudable but it comes from the top and hitting out at others doesn't set a good foundation. I'd recommend rising above by responding to critique without emotion.
  • deleted 5y ago
    [deleted]
  • nyanpasu64 5y ago
    There was a prominent member of the software community arguing in the LWN thread that authors of compilers which don't statically reject use-after-free (presumably including C and Hare) should be held liable for the consequences of use-after-free errors. And I suspect this person doesn't think the rustc developers should be sued for bugs written in unsafe Rust. I would argue that this person, not Drew DeVault, is hitting out at others.
    • staticassertion 5y ago
      Tony Hoare stated that language creators should be responsible for the bugs that users of those languages create. Is Tony Hoare a rust evangelist, or a "moral crusader" ?
      • nyanpasu64 5y ago
        Such a policy would create a chilling effect on the creation of practical languages which don't refuse to compile unproven code (every language in wide use).
        • pwdisswordfish9 4y ago
          Exactly!
    • 5y ago
• tayistay 5y ago
  Deleted... thanks for the clarification.
  • deleted 5y ago
    [deleted]
  • mplanchard 5y ago
    I think GP was implying the person who said it was unethical was trolling, not the author of Hare
• pjam 5y ago
  Assuming the "criminally prosecuted" piece is a reference to that thread [1], based on what other comments have also pointed out, did anyone in there actually say that, or imply it? I read that thread and didn't see anything close to that, there is clearly harsh language in there, such as: > Look if you can't understand that this is a thing that will happen in the real world and that people will potentially suffer as a result you shouldn't be writing a crypto library. Which is still far from suggesting someone should be prosecuted. [1]:https://lwn.net/Articles/893327/ https://lwn.net/Articles/893327/
  • nyanpasu64 5y ago
    Search for "liable" in the parent thread, https://lwn.net/Articles/893285/ https://lwn.net/Articles/893285/. That's the closest thing I could find.
    • pjam 5y ago
      Ha, perfect, exactly what I was looking for, thanks for pointing it out, didn't realize I was looking at a subsection of the thread, my bad. But it confirms what I was thinking, going from "liable" to "criminally prosecuted" is a pretty big stretch imo.
      • verdagon 5y ago
        What's the difference? (for a legal layperson like me)
        • pjam 5y ago
          I am not qualified to make any comments on the legal difference between the terms either, and I should also add that I am an ESL, so take that with a grain of salt. Reading the original comments about being "liable", it felt like another way of saying "there are consequences to your decisions, and as the author you bear some responsibility of what you put out there", which imo is pretty far from how the author of this blog post described it, hence me calling "a pretty big stretch"
• mjg59 5y ago
  That seems to be a reference to https://lwn.net/Articles/893346/ https://lwn.net/Articles/893346/ - I'll let people come to their own conclusion about whether Drew's framing matches that, but I will say that I've never written a line of Rust in my life and certainly can't be described as representing the Rust community in any way. My position here is based on spending my days dealing with the consequences of bugs that we know how to get rid of - I just don't see the excuse for building something that isn't at least as good as solutions that already exist, especially when the consequences are potentially so significant.
  • verdagon 5y ago
    If you've never written a line of Rust in your life, then your position could be more informed. I've written a lot of Rust, and see how much one sacrifices to get the memory safety guarantees without losing speed or memory safety. You can't make basic observers, RAII, dependency injection, back-references, or a lot of other useful patterns, without sacrificing speed or safety.
    • staticassertion 5y ago
      I'm experienced in security and rust and I agree with mjg. I've probably written 100s of thousands of lines of Rust, and I've been in security for well over a decade. None of what you said is even true, all of those patterns are trivial, except "back-references" which are very slightly non-trivial. And none of it is relevant. We don't need another memory unsafe language. It's fine if it's a toy, but this obviously isn't. It causes real harm.
      • verdagon 5y ago
        Everything I said is true. They all rely on having a mutable member reference to affect the outside world, which the borrow checker rejects. You can try to make it happen with a generic lifetime parameter for your structs, but you end up making invisible the thing you're pointing at, making it useless. One can use unsafe to have shared mutability, or sacrifice speed with Rc/RefCell (increments/decrements) or Cell (copying, especially bad when copying Vecs which causes heap allocations). Basic observers aren't possible. The closest thing we can get is some sort of modified observer-like substance that returns a command, which requires a lot of wiring and incidental complexity. [0] [1] Dependency injection (the pattern, not the framework) isn't viable for the same reasons as observers: you can't have a mutable reference field without causing a lot of headaches elsewhere. RAII isn't possible without sacrificing speed or safety. Most usages we see are backed by unsafe (FFI) or RefCell. We can't have multiple objects whose drop() affects the outside world, because we can't have multiple extant &mut references, and we can't just pass them in via parameters (because drop takes none). Back references aren't possible because of the circular problem (having a mutable reference to your owner means nobody else can read it). I'm not advocating for Hare, I'm just addressing the "I just don't see the excuse" remark, which can be ignorant of the costs of the borrow checker. The borrow checker is a great step forward, but not always a good tradeoff. An architect needs to be aware of these sacrifices before going all-in on a paradigm. [0] https://stackoverflow.com/questions/37572734/how-can-i-implement-the-observer-pattern-in-rust https://stackoverflow.com/questions/37572734/how-can-i-imple... [1] https://www.reddit.com/r/rust/comments/pwqju6/is_there_an_underlying_reason_that_idiomatic_rust/ https://www.reddit.com/r/rust/comments/pwqju6/is_there_an_un...