Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.adacore.com

Post reply on HN
Print view View original

111–120 of 173 posts

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

#111

Post by pjmlp »

HelloNurse wrote: post #110
pjmlp wrote: post #108

Earlier quoted context omitted.

Hardly any different, trying to pretend Python is somehow better. Operator overload is indeed syntactic sugar for function calls, regardless of the language. By the way, you can overload >> in Python via rshift(), or __rshift__() methods.

Of course I can overload >> in Python, but I cannot foul up output stream state because it doesn't exist. Formally there is little difference between C++ and Python operator overloading and both languages have good syntax for it, but C++ has many rough edges in the standard library and intrinsic complications that can make operator overloading much more interesting in practice. For instance, overload resolution is ra…

It is only one pip install away, if anyone bothers to make on such set of overloads.

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

#112

Post by AlotOfReading »

blub wrote: post #62
AlotOfReading wrote: post #56

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…

You mean memory-safe Rust is the default. Taking this default is not enough to write safety-critical software… but it’s enough to write a browser (in theory) or some Android core daemons.

Unfortunately, no. "Memory safe rust" is a more general concept than "Safe Rust". "Safe rust" is a generally understood term for the subset of rust that's everything outside unsafe blocks. Here's an example where it's used in the language docs [0]. "Memory safe rust" also includes all the unsafe code that follows the language rules, which is ideally all of it.

I can see how this would be confusing and probably should have been clarified with emphasis in the original comment. Safety in the sense of "safety critical" isn't a property any programming language can have on its own, so I wouldn't have intended that regardless.

[0] https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html

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

#113

Post by ecshafer »

oguz-ismail wrote: post #39
ecshafer wrote: post #22

Earlier quoted context omitted.

It is not saying that it is not possible to make C code that is safe enough to be on an airplane. Its that there are languages with additional features which make it easier to have a high confidence. If you can remove entire classes of bugs automatically, why not do so?

> Its that there are languages with additional features which make it easier to have a high confidence. If you can remove entire classes of bugs automatically, why not do so? Which languages remove which classes of bugs entirely? This vagueness is killing me

This is comparing C, C++, ada, Spark and Rust.... I think its obvious.

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

#114

Post by AlotOfReading »

uecker wrote: post #72
AlotOfReading wrote: post #56

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

I'd be happy to explain at length why the existing tools and standards are insufficient if you want. It'd be easier to have that discussion over another medium than HN comment chain though.

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

#115

Post by NekkoDroid »

bluGill wrote: post #90
NekkoDroid wrote: post #83

Earlier quoted context omitted.

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.

I guess I should have said `unique_type>` then :) Then you can do the same as std::chrono::duration does.

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

#117

Post by Pet_Ant »

forthac wrote: post #25
markasoftware wrote: post #13

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?

This was posted to about a day ago: https://github.com/johnperry-math/AoC2023/blob/master/More_D... But a noteworthy excerpt: ``` Ada programs tend to define types of the problem to be solved. The compiler then adapts the low-level type to match what is requested. Rust programs tend to rely on low-level types. That may not be clear, so two examples may help: Ada programmers prefer to specify integer types in terms of…

> By contrast, the Rust programs I've seen tend to specify types in terms of low-level, machine types.

This seems to be an artifact of the domain that Rust is currently being used in. I don't think it's anathema to Rust to evolve to be able to add some of these features. char indexed arrays are something I've used a lot (most via `char c - 'a'`\, but native support for it would be nice).

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

#118

Post by quotemstr »

boxed wrote: post #66
markasoftware wrote: post #13

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?

Aside from technical factors, there are social factors involved. For example, both Python and C++ has operator overloading. But in C++ that's horrible and you run screaming from it, while in Python land it's perfectly fine. What is the difference? Culture and taste.

> Culture and taste.

You mean accumulated prejudices, myths, and superstitions that most in any given community (programming language related or not) won't challenge for fear of being cast out of the group for heresy.

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

#119

Post by quotemstr »

boxed wrote: post #104
HelloNurse wrote: post #73

Earlier quoted context omitted.

It isn't the same operator overloading. In C++ operator overloading can easily mess with fundamental mechanisms, often intentionally; in Python it is usually no more dangerous than defining regular functions and usually employed purposefully for types that form nice algebraic structures.

It's the exact same thing except in Python the community largely has taste. In C++ `cout >> "foo"` exists in the standard library.

I love how among a certain set the word "taste" has become an all-purpose substitute for having an argument or making a case. It basically means "I have more social media follows than you do, so I'm right"
Post reply on HN