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

101–110 of 173 posts

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

#101

Post by pjmlp »

firesteelrain wrote: post #7

I know there is a belief that Rust/Ada etc is safer than C/C++ and in some cases that is true. I know of multiple, airworthy aircraft that are flying with C++ code. I also know of aircraft flying with Ada. The aircraft flying with Ada is hard to maintain. There is also a mountain of testing that goes into it that is not just unit testing. This mountain of integration, subsystem and system level testing is required re…

Yes, by putting C and C++ into a straighjacket of formal verification and code practices that would make most complaints about Rust's borrow checker seem like child play.

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

#102

Post by pjmlp »

1718627440 wrote: post #84
smj-edison wrote: post #51

Earlier quoted context omitted.

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

Like in most languages, with indexes.

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

#104

Post by boxed »

HelloNurse wrote: post #73
boxed wrote: post #66

Earlier quoted context omitted.

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.

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.

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

#105

Post by HelloNurse »

pjmlp wrote: post #100
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.

I hardly see the difference, given the capabilities of operator overloading in Python, class MyNum(int): def __add__ (self, other): return super().__add__(other) * 10 n = MyNum(12) a = 45 print(n + a) # oops

This type confusion would have been identical with a plain function, __add__ is only syntactic sugar:

    class MyNum(int):
        def ten_times_sum (self, other):
            return (self+other)* 10

    n = MyNum(12)
    a = 45
    print(n.ten_times_sum(a))
Compare with, for example, fouling the state of output streams from operator>> in C++.

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

#106

Post by bluGill »

pjmlp wrote: post #93
bluGill wrote: post #90

Earlier quoted context omitted.

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.

Thankfully some folks already thought that out, one possible library, https://mpusz.github.io/mp-units/latest/

I have seen several versions. I wrote two different ones myself - both not in use because the real world of units turned out far more complex. the multiplication thing is one simple example of the issuses but not a complete list

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

#107

Post by gosub100 »

firesteelrain wrote: post #7

I know there is a belief that Rust/Ada etc is safer than C/C++ and in some cases that is true. I know of multiple, airworthy aircraft that are flying with C++ code. I also know of aircraft flying with Ada. The aircraft flying with Ada is hard to maintain. There is also a mountain of testing that goes into it that is not just unit testing. This mountain of integration, subsystem and system level testing is required re…

What needs to be "maintained" in a flying aircraft? If it's in need of an update, why was it certified to fly that way in the first place?

Also in safety critical apps, being "difficult" can be a feature, not a big. Should we have easier turbofans so we can pop them open and swap out blades and rings for tiny little improvements? No. Every flight critical component should be fully understood as a prerequisite for use.

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

#108

Post by pjmlp »

HelloNurse wrote: post #105
pjmlp wrote: post #100

Earlier quoted context omitted.

I hardly see the difference, given the capabilities of operator overloading in Python, class MyNum(int): def __add__ (self, other): return super().__add__(other) * 10 n = MyNum(12) a = 45 print(n + a) # oops

This type confusion would have been identical with a plain function, __add__ is only syntactic sugar: class MyNum(int): def ten_times_sum (self, other): return (self+other)* 10 n = MyNum(12) a = 45 print(n.ten_times_sum(a)) Compare with, for example, fouling the state of output streams from operator>> in C++.

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.

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

#109

Post by firesteelrain »

gosub100 wrote: post #107
firesteelrain wrote: post #7

I know there is a belief that Rust/Ada etc is safer than C/C++ and in some cases that is true. I know of multiple, airworthy aircraft that are flying with C++ code. I also know of aircraft flying with Ada. The aircraft flying with Ada is hard to maintain. There is also a mountain of testing that goes into it that is not just unit testing. This mountain of integration, subsystem and system level testing is required re…

What needs to be "maintained" in a flying aircraft? If it's in need of an update, why was it certified to fly that way in the first place? Also in safety critical apps, being "difficult" can be a feature, not a big. Should we have easier turbofans so we can pop them open and swap out blades and rings for tiny little improvements? No. Every flight critical component should be fully understood as a prerequisite for use…

There are new features or new subsystems to integrate which require ICD updates or bug fixes that need fixing.

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

#110

Post by HelloNurse »

pjmlp wrote: post #108
HelloNurse wrote: post #105

Earlier quoted context omitted.

This type confusion would have been identical with a plain function, __add__ is only syntactic sugar: class MyNum(int): def ten_times_sum (self, other): return (self+other)* 10 n = MyNum(12) a = 45 print(n.ten_times_sum(a)) Compare with, for example, fouling the state of output streams from operator>> in C++.

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 rarely trivial.
Post reply on HN