Live data from Hacker News

Should I choose Ada, SPARK, or Rust over C/C++? (2024)

blog.adacore.com

81–90 of 173 posts

Re: Should I choose Ada, SPARK, or Rust over C/C++? (2024)

#81

Earlier quoted context omitted.

> These are subsets of their respective languages, but Pretty much every language has such a subset. Nothing new then, sigh...

C and C++ don't have such a subset. That seems pretty relevant, given they're the languages being compared and they're used for the majority of safety critical development. The standards I mentioned use tricks to get around this. MISRA, for example, has the infamous rule 1.3 that says "just don't do bad things". Actually following that or verifying compliance are problems left completely to the user. On the other han…

Memory safety doesn't really help that much with functional safety.

Sure, a segfault could potentially make some device fail to do its safety critical operation, but that is treated in the same way a logic bug would be, so it's not really a concern in of itself.

But then again, an unchecked .unwrap() would lead to the same failure mode, so a "safe" crash just just as bad as an "unsafe" one.

Re: Should I choose Ada, SPARK, or Rust over C/C++? (2024)

#82
I might be in the minority, but I hate type re-definitions, I want types to just tell me how much memory a variable is using and it’s bit interpretation. Every variable already has a name, use that to communicate the data’s representation and if it’s really important that representation mismatches are caught at compile time wrap it in a struct. I don’t want to guess how much memory the compiler decided a variable needed (though that is also present to an extent in C/C++)

Re: Should I choose Ada, SPARK, or Rust over C/C++? (2024)

#83
post #44

Earlier quoted context omitted.

I'm super interested how you can do this in C++. Say, I need aggregate struct with a few 16 and 32 bit fields, some are little endian and some big endian. I do not want C++ to let me mix up endianness. How do I do it?

C: struct be32_t { uint32_t _ }; struct le32_t { uint32_t _ }; C++: That, but with a billion operator overloads and conversion operators so they feel just like native integers.

In C++ you probably could even make a templated class that implements all possible operators for any type that supports it with concepts. Then you can just `using kilometer = unique_type` without needing to create a custom type each time.

Re: Should I choose Ada, SPARK, or Rust over C/C++? (2024)

#84

Earlier quoted context omitted.

Most of what gives high-reliability or high-assurance code that label is the process rather than the language. In colloquial terms it rigorously disallows sloppy code, which devs will happily write in any language given the chance. As much as C is probably the least safe systems language, and probably my last choice these days if I had to choose one, more high-assurance code has probably been written in C than any ot…

> Most of what gives high-reliability or high-assurance code that label is the process rather than the language. This is what I've heard too. I have a friend who works in aerospace programming, and the type of C he writes is very different. No dynamic memory, no pointer math, constant CRC checks, and other things. Plus the tooling he has access to also assists with hitting realtime deadlines, JTAG debugging, and othe…

> no pointer math

How does that work out? Does he never uses arrays and strings?

Re: Should I choose Ada, SPARK, or Rust over C/C++? (2024)

#85
post #81

Earlier quoted context omitted.

C and C++ don't have such a subset. That seems pretty relevant, given they're the languages being compared and they're used for the majority of safety critical development. The standards I mentioned use tricks to get around this. MISRA, for example, has the infamous rule 1.3 that says "just don't do bad things". Actually following that or verifying compliance are problems left completely to the user. On the other han…

Memory safety doesn't really help that much with functional safety. Sure, a segfault could potentially make some device fail to do its safety critical operation, but that is treated in the same way a logic bug would be, so it's not really a concern in of itself. But then again, an unchecked .unwrap() would lead to the same failure mode, so a "safe" crash just just as bad as an "unsafe" one.

Memory safety (as defined by Rust) actually goes a very long way to help with functional safety, mostly because in order to have a memory safe language, you need a number of additional language features that generally aid with correctness.

For example, lifetimes are necessary for memory safety in Rust, but you can use lifetimes much more generally to express things like "while this object exists, this other object is inaccessible", or "this thing is strictly read-only under these particular conditions". That's very useful.

Re: Should I choose Ada, SPARK, or Rust over C/C++? (2024)

#86
post #72

Earlier quoted context omitted.

C and C++ don't have such a subset. That seems pretty relevant, given they're the languages being compared and they're used for the majority of safety critical development. The standards I mentioned use tricks to get around this. MISRA, for example, has the infamous rule 1.3 that says "just don't do bad things". Actually following that or verifying compliance are problems left completely to the user. On the other han…

C and C++ don't have such subset defined as part of their standard. Left to users means left to additional tools, which do exist. Rust only has memory safety by default, this is a small part of the problem and it is not clear to me that having this helps with functional safety. (Although I agree that it helps elsewhere).

If you think a strong and convenient type system helps with functional safety, then Rust helps with functional safety. This is also generally the experience in the industry.

Re: Should I choose Ada, SPARK, or Rust over C/C++? (2024)

#87

Earlier quoted context omitted.

It’s a common misconception that the point of Rust is just security. Rust helps avoid a very broad class of bugs, that security bugs are only a subset of.

They'd simply tell you that by just magically "getting better" at C/C++, those would be resolved too. And if my grandmother had wheels, she'd have been a bike [0]. It's like a JRPG that may be a slog at the beginning, but then really gets going after the first 50-60 hours. Just gotta replace the hours with years, and huff even more glue. And these are the people moaning about Rust and religious thinking... good old D…

In the RPG analogy, why waste your skill points on maxing out "checking code for UB", when you can get +10 bonus on UB checks from having Rust, and put the skill points into other things.

Re: Should I choose Ada, SPARK, or Rust over C/C++? (2024)

#88
post #43

No, just learn C/C++ properly.

I've worked with some of the best C++ programmers on the planet, and none of them would ever propose this as a solution. They are the first to recognize that developing software in C++ is expensive and error-prone.

We've tried this for decades.

Re: Should I choose Ada, SPARK, or Rust over C/C++? (2024)

#89

Their example of why Ada has better strong typing than Rust is that you can have floats for miles and floats for kilometers and not get them mixed up. News flash, Rust has newtype structs, and you can also do basically the same thing in C++. I don't know much about Ada. Is its type system any better than Rust's?

There is no elegant solution in Rust to make something like type Temperature_K is digits 6 range 0 .. ;

at least that is an unsigned (though there are no usigned hardware floats). If you said tempemerature C there you range starts at -273.15 and you want errors of some sort to happen if you go below that.

Re: Should I choose Ada, SPARK, or Rust over C/C++? (2024)

#90

Earlier quoted context omitted.

C: struct be32_t { uint32_t _ }; struct le32_t { uint32_t _ }; C++: That, but with a billion operator overloads and conversion operators so they feel just like native integers.

In C++ you probably could even make a templated class that implements all possible operators for any type that supports it with concepts. Then you can just `using kilometer = unique_type ` without needing to create a custom type each time.

Though if you do that km times km isn't km it is a volume - so your custom type would be wrong to have all operations. what unit km times km should be isn't clear.
Post reply on HN