Hacker News Reader

Comment by boznz | Hacker News Reader

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 embedded languages like ADA?

Note it wont affect me as I mainly use PIC micros

View on HN

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.

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

Sadly languages with Algol like syntax are not fashionable any more, now being cool is having an ML like syntax, hence the momentum.

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.

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.

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.

Its type system certainly does not prevent memory errors.

It prevents certain classes of memory errors.

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.

Yes, the expressive type system with zero-cost abstractions that makes me really excited about this!

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.

You absolutely can write unsafe programmes in Rust. In fact, you absolutely HAVE to do so to do anything useful on a microcontroller.

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.

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.

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

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.

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

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.

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?

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.

Unsafe should only be needed at the edges of the program, in dealing with IO. These parts should always (not just with Rust) be put in some platform layer used by the application code. This allows the majority of the application code to be verified easily, with unit-tests, end-to-end tests as well as writing simulations. Done right the verification can be ran both on host and on-device. Another key benefit is that this allows to develop majority of the software before the hardware is ready. When possible, use a platform abstraction which is already tested. As verification of this code is harder, typically requiring hardware and external interactions.

I hope that Rust unsafe/safe concept makes the platform/applogic boundary more visible and explicit, so people follow these practices more often.

Reply on news.ycombinator.com