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.

Not really. We can simply expand it to "All code has bugs", and then we're simply at Rice's theorem. In C, the class of bugs that can not be proven to not exist are also quite dangerous - remote code execution, as an exemplar consequence. In rust, you're limited to a program that can crash, or that has other semantic faults.

So it's clearly not wrong, and is actually a totally well established idea well outside of the context of rust or C.

An 8-bit AVR executes instructions from on board flash memory that requires twiddling hardware lines to erase and rewrite.

Remote code execution isn't a concern.

AVR ATMega is self programmable ie a bootloader can re-flash it if its configured to allow but you would need some code already resident on the flash to allow, it couldnt be done without this code.

No, but memory corruption related to pointers misuse or unsigned arithmetic is.

(I think you mean signed arithmetic here and in your almost-sibling comment.)

Probably, I always mix them up.

You can very easily have all the sorts of memory unsafety you have in C, in Rust.

Only in sections marked as unsafe.

In C every single line of code that manipulates pointers, does string operations, uses arrays or unsigned arithmetic is a possible cause of memory corruption.

Most code is less-than-perfect, independently of language. But the consequences of this depends on the language.

IMHO There's a big gap between perfectly written and poorly written

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.

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)

The answer is basically "stack probes", yes.

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?

They're runtime checks, but they're inserted by the compiler at compile time. So yeah, if you link in code that wasn't compiled with them, then that code isn't protected.

You're right that a summary seems hard to find; http://www.delorie.com/gnu/docs/gcc/gccint_124.html has some decent stuff in it, but given that it's random GCC docs, the details may not be 100% accurate today, I dunno, I'm on a flight layover right now, so that's all I've got at the moment :)

They're dynamic checks.

Static checks for stack overflows are infeasible.

They are not infeasible, if you are willing to limit what your language can do.

Doing so doesn’t remove all useful programs, as the first Fortran compilers showed (they used a fixed addresses for all variables, be they local or global (that they did not support recursion is not that surprising, given that many CPUs of the time didn’t have a return stack))

That’s why I asked whether Rust supported such a thing. It would be very helpful, for example, if your build system would tell you that that difficult to test error handler would, if called, overflow the stack before you spent time and, possibly, lots of money, on trying to run it.

> That typically would prevent the use of recursion, but that's not too bad

It also prevents the use of indirect calls/virtual functions, because they can hide recursion. That's Bad.

It's fairly trivial to overflow a buffer in Rust. I don't consider having to write "unsafe { /* overflow buffer code goes here */}" non-trivial.

The difference is that when you are forced to declare where your program does not follow some safe semantics, while it's still trivial to write an overflow, it's also trivial (or at least not nearly as complex as some alternatives) to find and fix, compared to a language where the entire code base is a possible source for those problems.

For comparison, I would say C and C++ (but to a slightly lesser degree) are also trivial to write buffer overflows in, it is definitely non-trivial in many cases to find and fix those problems, as the surface area is so large.

To illustrate this, it's trivial to write a buffer overflow in almost all languages that provide any sort of raw memory access or hardware instructions (ASM), even if through a module. It's trivial for me to create a buffer overflow in Python or Perl my including a module that allows direct assembly code access. The difference when using those languages is that when I run into a buffer overflow problem, I can be reasonably sure it's in a place where I bypassed the assurances provided by those languages, or in some included module that did the same (including just using a shared library). When tracking down a problem like that, I'll focus my attention on those spots, which makes identifying and hopefully fixing those problems easier.

Rust's "unsafe" is really an in-language way to provide a similar set of levels of assurance about how likely the code is to have problems of specific types, with assurances provides by the language and compiler. This is a step above what C and C++[1] provide, and thus welcome.

1: C++ provides some similar assurances based on types, but by nature of how "safe" code becomes "unsafe" when used in conjunction with unsafe portions, is much harder to assess at a block level, since you can't even be sure a line is safe until you've verified all the types used within it.

For embedded code, I'd recommend that all application code should be compiled with the `--deny unsafe-code` option. Then the compiler will stop you. A separate module for the I/O code providing is the only place where one should use `unsafe`. Extra care must be taken here, in code review and in testing.

Do you have any idea how impossible it is to do anything useful without unsafe in Rust on a microcontroller?

About as hard as on desktop? I mean, many of the core datastructures commonly used there are implemented using unsafe. This does not mean that the application code must or should be riddled with unsafe code blocks... For a very simple example see https://github.com/hackndev/zinc/blob/master/examples/blink_...

If Ada, Pascal and Basic can, so can Rust.

Every case where this is not true is a bug.

You can also get a buffer overflow in Python and Java by abusing their equivalents of "unsafe".

"unsafe" in Rust isn't abuse. It's explicit syntax with compile time effects specifically for the purpose of facilitating unsafe constructs, like direct memory buffer manipulation, required for low level programming.

I've never tried the Python or Java equivalents and frankly don't know enough about them to even know whether your comment is accurate or not.

Java has `sun.misc.Unsafe`, and Python has the FFI which is remarkably easy to misuse. The point is that you don't use these unless you need to, and you spend special effort when you do - same as `unsafe` in Rust. The rest of your code runs perfectly safely, and the vast majority of code has no need to use `unsafe`. Code which uses `unsafe` and isn't obviously either directly an FFI wrapper or a straightforward implementation of a generic data structure is generally considered bad form.

True that unsafe isn't considered too wrong in rust, but auditing the small amount of unsafe code is much easier than all the code.

Is getting that past the person who is reviewing your code also trivial?

Possibly. Depends on the quality of the reviewer and the complexity of the code (as a whole). On average Rust programmers aren't necessarily better than programmers using any other language. If history is a guide then if Rust takes off there will be plenty of terrible, buggy, unsafe and very thoroughly reviewed Rust code out there used in popular, widely used applications or services.

I find the notion that "explicit unsafe makes bugs less likely" to be suspect. It seems reasonable, almost tautological at first glance. But theory and practice are different animals.

It certainly is possible in Rust. Rust is not memory safe.

As it is in any language that has FFI to Assembly.

But that is a big difference in the amount of unsafety per line of code.

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.

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.

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

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.

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?