9 ms·

I dont know rust from jack so I am interested to know why it will compile a safer program than a well written C one and what makes it better than other safe emb

• deleted 10y ago
  [deleted]
• nrclark 10y ago
  You gain Rust's memory-safety, but also you gain all of its meta-programming facilities. Which means all those #define macros become a thing of the past.
  • jononor 10y ago
    Yes, the expressive type system with zero-cost abstractions that makes me really excited about this!
• pjmlp 10y ago
  The best thing Rust has over Ada (no one writes ADA any more :) ) is momentum. Although Ada has eventually got an open source compiler, and there are still around 5 vendors available, due to the way it got sold, its key use has been in the area of High Integrity Computing. So unless that is the domain of the work, where no errors are allowed, which could possibly lead to loss of human lives, very few care of using Ada. For the young generations, Ada is kind of something they hear it existed but they never seen live, even though it has enjoyed a regular presence at European FOSS conferences like FOSDEM. So by being modern, Rust can appeal more to the younger generations, also some type system safety rules of Rust for parallel code can only be coded in Ada via SPARK.
  • jonathonf 10y ago
    > The best thing Rust has over Ada (no one writes ADA any more :) ) is momentum. Having only recently looked at Ada I don't really understand this. It does look like Ada offers a lot of really nice features that other languages haven't yet caught up to. For example, SPARK allows formal definition of correct code behaviour within the function definition. This appears to me to mean tests are written into the function at the time you write the function. That's huge from a maintenance standpoint, and it likely provides extra information a compiler could take advantage of. > where no errors are allowed, which could possibly lead to loss of human lives, very few care of using Ada. Loss of life is one area, but surely anything financial would benefit from this - as well as anything dealing with personal data (e.g. identity management)?
    • pjmlp 10y ago
      Sadly languages with Algol like syntax are not fashionable any more, now being cool is having an ML like syntax, hence the momentum.
• loeg 10y ago
  No difference between AVR and x86 here. Rust has some memory protection guarantees that distinguish it from C. You simply cannot write some kinds of unsafe programs in Rust that you could in C. If your C programs are correct, there is no safety problem. I can't speak to Ada.
  • milesrout 10y ago
    You absolutely can write unsafe programmes in Rust. In fact, you absolutely HAVE to do so to do anything useful on a microcontroller.
    • pcwalton 10y ago
      You have to do so to do anything useful at all. I/O is written using unsafe code. That doesn't mean that Rust has no safety properties. It just means you have a TCB of nonzero size.
      • milesrout 10y ago
        No, it does mean Rust has no useful safety properties. To do anything, you have to trust a lot of code. The reality is that one of the core selling points of the language was discovered to be unsafe due to some particularly complex combination of library features right before the 1.0 release. Was that patched? Sure. But the idea that it was the only unsound bit of code is absurd. There are almost certainly more in there, many more.
        • pcwalton 10y ago
          > No, it does mean Rust has no useful safety properties. To do anything, you have to trust a lot of code. That's also true with any memory-safe language ever: you have to trust the compiler and VM. So if we accept your claim, then we also have to accept the claim that no memory-safe language has any useful safety properties. Needless to say, this is contrary to all the evidence. > The reality is that one of the core selling points of the language was discovered to be unsafe due to some particularly complex combination of library features right before the 1.0 release. Consider the chain of events that would have to happen to cause this unsoundness to lead to real-world problems (say, RCE), and compare that to the chain of events that routinely happen in order to cause a use-after-free in C++ to lead to the same problems. One is vastly more probable than the other.
• foota 10y ago
  You don't get advantages over perfectly written C, but that doesn't exist. Over mortal written C, you gain safety against data races, use after free, and a couple other classes of errors. And without needing manual memory management, and with high level ergonomics.
  • milesrout 10y ago
    The idea that C code is always poorly written is both wrong and offensive.
    • vertex-four 10y ago
      Not poorly written, just it's very easy to forget things, and even very well-written, readable, documented C code usually has memory-related bugs, as long as it's written by fallible humans. Nearly every networked C program in existence has had a buffer overflow CVE at some point - that's simply not possible in Rust.
      • Someone 10y ago
        Corrrections welcome, but I think there is one buffer that you can overflow in every Rust program: the stack. If you have a MMU, the runtime will/should protect against that by mapping a page as 'trap on write' and panicking/rebooting/signaling if you do, but if you don't, I don't think rust has any functionality to prevent it. Or can you declare that your stack is x bytes, and have the compiler verify that no call chain will need more? (That typically would prevent the use of recursion, but that's not too bad)
        • steveklabnik 10y ago
          The answer is basically "stack probes", yes.
          • Someone 10y ago
            I find very few relevant hits on that on Google (stack probes apparently also are hardware to measure various quantities such as moisture in stacks of materials), and none that explain to me what they are (you can enable them in gcc and Microsoft's compilers, and rust should use them instead of stack overflow checks, but that's about it), but from what I guesstimate, they are runtime instrumentation, not anything that a rust compiler could do to guarantee that a compiled and linked program never overflows the stack. Can you tell me more about them?
• adrianN 10y ago
  Maybe read up on Rust. Its type system prevents memory errors. To use after free, no use of invalid iterators, no buffer overflows. No data races in multithreaded code. It's pretty cool.
  • milesrout 10y ago
    Its type system certainly does not prevent memory errors.
    • pcwalton 10y ago
      It prevents certain classes of memory errors.
• milesrout 10y ago
  It won't. To do anything useful on a microcontroller you would have to drop into 'unsafe' so often that any idea of safety is out of the window.
  • pcwalton 10y ago
    > It won't. To do anything useful on a microcontroller you would have to drop into 'unsafe' so often that any idea of safety is out of the window. I don't think that's true. I'm writing an OpenGL library right now, diving into "unsafe" all the time to issue the FFI calls, and there's a measurable difference in the number of memory safety problems I've seen (zero thus far) compared to what I see in C++. I think the friction of writing "unsafe" encourages small isolated abstractions.
    • milesrout 10y ago
      In other words you're just writing Rust the way anyone competent writes C in the first place: being careful. You think that the language forces you to be careful, I think what's more likely is that Rust is so difficult and aggravating to use that it discourages the sorts of morons that introduce those errors from using it in the first place.
      • pcwalton 10y ago
        The idea that people who create security flaws in C are "morons" is contrary to all the evidence. In fact, the biggest security problems are usually caused by the best programmers. That's because they write the code that people actually use a lot. To be concrete: libpng, libjpeg, FreeType, etc. are not written by "morons". Can you write a JPEG decoder faster than libjpeg-turbo?
      • pjmlp 10y ago
        Somewhere out there do exist these ideal C developers that write perfect safe code. Sadly in more than 30 years of career I never met one. Not even the BSD and Linux kernel devs, given the amount of entries on the CVE database. Even Dennis complained about this, regarding the genesis of lint. So I wonder where do they exist.
• sidlls 10y ago
  Rust provides compile-time safety guarantees. Safe code is possible in well-written C, but it can't be proven safe. I think that's a small difference with larger implications: the C code requires more thorough and competent human review for safety. I don't think the "incompetent C programmer writing code that is unsafe and that is always and uniformly bad" is as prevalent as it seems HN does, so I consider even the "human review" implication not that significant. As for better, that is in the eye of the beholder. I've never used embedded ADA, but I've slung my fair share of ADA code in higher level applications. For me, for reasons I couldn't describe, the syntaxes and grammars of C-like languages (C++, Rust) just feel more comfortable. ADA is a fine language, though, and a real pleasure to work with, too (it reminded me a lot of Pascal, which is what I learned in school). Here's something else to consider, however: Rust (core rust, even without the stdlib) provides a fantastic set of built-in abstractions that would require lots of up-front development effort if one used C.