Hacker News Reader

> - Easy to implement the language specification. All features should be easy to understand.

I'm not sure this is at all applicable to rust. Perhaps once there are more than the one, quickly mutating, implementation, we can say that it's easy to implement the specification.

> - Reliability. The language should aid the design and development of reliable programs.

This one feels a touch questionable, given the built-in "succeed or die" macros that simplify code at the cost of reliability. There's also the unsafe keyword, and how the impact of an unsafe operation in one section of code (say, an imported library) can have negative impacts on unrelated sections of code otherwise deemed safe.

> - No unnecessary complexity. Semantic structure should be consistent and minimize the number of concepts.

Borrow checker aside, there is a ton of complexity in Rust (traits, multiple flavors of arrays, multiple flavors of boxed values).

> - Machine independence. The language shall not be bound to any hardware or OS details.

Rust relies on the LLVM project to provide this, and relies on the contributors to the LLVM project to target different architectures.

> given the built-in "succeed or die" macros that simplify code at the cost of reliability

Most of those are linted for, so you can use them to speed development but still be aware that they shouldn't be there in production code.

These points are around language design and implementation; linting is an additional set of tools outside the scope of the language itself.

Whether it should or shouldn't be in production, following Ada's rules it wouldn't be allowed in the code in the first place.

I'd argue that lints are part of the language - they are run as part of the compiler, and block code from compiling, like the "must use" lint.

That said, they are configurable, so I see your point - they are more permissive than what Ada allows

OTOH, I believe you can turn lint warnings into hard errors for only production, allow for fast development but programmatically disallowing them from reaching production. But again, thats configurable.

> ...unsafe operation in one section of code (say, an imported library) can have negative impacts on unrelated sections of code otherwise deemed safe.

Yeah. Just like every line in C/C++ code can have negative impacts on unrelated sections.

While true, that talking point feels somewhat unfair or even in bad faith. Rust requires "unsafe" escape hatch to be able be a low level systems language. Or gasp, to call libraries using C ABI.

I write a lot of low level code in C/C++ (firmware, kernel drivers, low level services) and I think a C ABI compatible "runtimeless" safe language, like Rust, dramatically improve security, safety and even ultimately provide faster time-to-market.

> C/C++

No such thing.

This comparison is against Ada's language criteria, not C/C++.

You're well above 100% right with your points, if we weren't looking at the language criteria put forth by Ada.

EDIT: It's worth nothing that Ada is also a system and embedded programming language.

Ada has unsafe code as well and messing it up causes exactly the same thing as it does in Rust or C++, so I'm not sure what your point is.

> given the built-in "succeed or die" macros that simplify code at the cost of reliability.

I would consider a program that dies early to be more reliable (but less robust) than one that just soldiers on, probably doing wrong (and possibly dangerous) things.

Regardless, it is the programmers choice whether to call panic!() or to try to handle an error gracefully and continue.

It depends on the situation. Ariane 5 was destroyed because its inertial reference system (written in Ada) died early instead of soldiering on, and as it turns out, it would have been fine if it had soldiered on.

Really, there's a certain amount of software, like the Ariane 5 SRI, for which the only acceptable outcome is not to have the error in the first place — there's no acceptable way to handle it once it happens. That software is very expensive to write, so you want to keep it to a minimum in the overall system, but sometimes you cannot avoid having some of it.

Rust cannot be used in most professional use cases where Ada programs can be deployed because the Rust toolchain isn't a qualified one for any of the various IEC 61508 derived qualification regimes.

Which is a shame, because Rust is a great fit for these use cases. Though there are a lot of ecosystem shaped things that present practical challenges too: things that should/could be in no_std but unnecessarily depend on std instead, a variety of cargo workflow issues, etc.

There's a group in Germany (I think) that proposed attempting to qualify Rust to get it approved for inclusion in the list of 61508 languages, but that proposal did not seem to be met with much enthusiasm.

We're using Rust to build tools to service those kinds of industries, and it's non-trivial to justify its use even in adjacent tooling. Let alone to be directly deployed to a target device.

> There's a group in Germany (I think) that proposed attempting to qualify Rust to get it approved for inclusion in the list of 61508 languages, but that proposal did not seem to be met with much enthusiasm.

https://ferrous-systems.com/blog/sealed-rust-the-pitch/

There's still a lot of interest; this stuff doesn't happen quickly.

I got the impression folks were lukewarm to it with concerns about what it would mean with respect to Rust's rolling release cycle and other shapes of incongruent goals between how to manage Rust as a big project and what it takes to maintain compliance for standards purposes.

I would be thrilled to death for that effort to move forward with zeal however. If a WG develops around it, I'd also happily provide engineering resources to coordinate and work on the effort.

I'm not directly involved, so I can't say too much, but the general advice of "comments on the internet are not representative" applies.

You should get in touch with the Ferrous folks, I'm sure they'd love to hear from you.

Might as well mention F* then!

> F* (pronounced F star) is a general-purpose functional programming language with effects aimed at program verification. It puts together the automation of an SMT-backed deductive verification tool with the expressive power of a proof assistant based on dependent types. After verification, F* programs can be extracted to efficient OCaml, F#, C, WASM, or ASM code. This enables verifying the functional correctness and security of realistic applications. The main ongoing use case of F* is building a verified, drop-in replacement for the whole HTTPS stack in Project Everest. This includes verified implementations of TLS 1.2 and 1.3 and of the underlying cryptographic primitives.

> Its type system includes dependent types, monadic effects, refinement types, and a weakest precondition calculus. Together, these features allow expressing precise and compact specifications for programs. The F* type-checker aims to prove that programs meet their specifications using a combination of SMT solving and interactive proofs.

https://www.fstar-lang.org/

And the "worst name" prize goes to ...

Go.

Still Go.

It's incredibly silly to want to insert Rust into every discussion and suggest every article written about something that Rust (sort of) does should mention it. It's not a good look for people not yet into Rust that this stuff is still happening, IMO.

In this discussion, Rust is actually relevant, nearest comparison I can think of.

It's not necessarily as much Rust as the desperate need to get something safer than C/C++ without compromising performance and interoperability.

>as the desperate need to get something safer than C/C++ without compromising performance and interoperability

Object Pascal

D

ATS

Common Lisp

Ada

even Fortran!!

the list can go on and on

I think the fact that all of those have been around for decades, and yet haven't gained much traction, implies that there's something wrong with them that makes them unsuitable.

If it's just a matter of marketing and failing the subjectivity of a popularity contest, that's a shame, but I wouldn't leap to assume that's the sole reason.

Go?

Being bundled with the OS SDK happens to be a big factor for adoption.

On the other hand, think that some of those languages have commercial compilers being sold for decades and they are still in business.

So, some companies do value the quality of the software they product.

> Where is the mention of other new programming languages that also fit this category? Where is the mention of Rust?

The article is about Ada. If you want to read about Rust, go read about Rust.

This article promotes Ada as the right language to use for systems programming; a good comparison would include a description of how it compares to other systems programming languages. History of why the DoD chose it in the 1970s, over the languages of the 1970s, doesn't explain why it's the right choice today.

I don't read the comment you're replying to as asking for an article about Rust or any other language. It's interesting to read about Ada, specifically. I would love to see descriptions of what Ada does better than other modern languages for systems programming. "Strong typing" is a feature of many non-C languages, for instance, but types with specific ranges aren't. And the "storage pool" mechanism deserves a more detailed comparison to other memory management approaches.

bluejekyll does chastise the author for not including their favorite programming language and I don't think that's a legitimate criticism at all.

Yes, most systems programming is done in C and C++. Some people even use Rust, I've heard. Doesn't mean that an article has to draw comparisons to these languages. In fact, almost every article comparing programming languages inevitably does a poor job at it because the author most likely is more familiar with one language and then we'd have people criticizing the author because they got X, Y and Z wrong.

I have seen this a lot of time on HN. It's simply smart to not compare languages.

If the article had a title of, "Ada is a great language for embedded", then great. But it's implying that Ada is the only language that exists today that can accomplish this task, and that's just not true. Rust is merely one example, and the best I know. And the tooling of these modern languages perhaps are better reasons to use them than Ada.

But yes, perhaps I was too critical, it's mainly the title that is a little misleading, and then the content didn't express anything specific about Ada that other languages don't also have.

It may not be obvious from the article title, but the article IS about using Ada for embedded systems programming. Here are the reasons that this is so:

1) The article is on Hackaday, a website for hardware hacking enthusiasts. Most programming articles on the site are geared toward low-level and embedded systems programming.

2) The end of the introduction section of the article ends with the line: "Ada might also be the right choice for your next embedded project."

3) The last section of the article "WHERE TO GO FROM HERE" points the reader to a related article about how to get started with Ada on a PicoRV32 RISC-V core, a small processor typically used in FPGA and ASIC designs, not the usual fare for desktop, server-side, or web programming.

Ada was designed for safety-critical, military-grade embedded systems programming. It excels in that domain and while it CAN be used for operating system and application programming, it requires a bit more effort than other programming languages because of the difference in idiomatic approaches and the built-in APIs.

That's not really the point I was making. Ada has been around since the 70's and at that time, was possibly the correct choice to make given the criteria. The question I asked at the end, and the title of this article, is why would I pick Ada today?

The best reason I've seen is because it's already passed the hurdles in some industries as being a compliant language for their needs. That might be a good enough reason for some, but it's not one that's important to me.

That seems like a trick question, because obviously you wouldn't pick Ada, you would pick Rust. And then you would talk about Rust, and mention how great Rust is, perhaps in a thread about Ada, which hadn't mentioned Rust at all. Or a thread about C, or about C++ or even about Go or why not even Python and JavaScript.

But seriously now: the author didn't mention Rust because they probably don't even know it exists. I work in embedded and like to ask people offering courses / tooling / services around safety if they support Rust and the only answer I got so far is "no". A lot of those people either don't know about Rust or they don't care, because everyone's using C and C++.

Hackaday has written several articles about Rust, though I don't believe any of them were by this author.

I'd really love to read a fair and comprehensive comparison and review of Ada and Rust. Safety, performance, concurrency, low level ABI compatibility etc.

Ada does seem interesting, but all the buzz seems to be about Rust. Perhaps Ada deserves more interest?

At least a short comparison of Ada/SPARK and Rust:

https://www.electronicdesign.com/industrial/rust-and-spark-s...

Thanks, while short, it sure looks interesting.

SPARK statically checked function pre- and postconditions and constrained types certainly look very interesting especially for embedded systems. And for a lot of other low level code as well.

Why can't someone write an article about Ada without it having to be about Rust?

Because they overlap almost entiely in use case?

From my own analysis, about a year ago, I do not believe this to be true. Rust is memory safe, but it does not offer the type system that Ada does. The type system is where a large portion of Ada's safety comes from. They're both tackling software/system safety, but from different directions and to different ends.

Additionally, modern Ada (after the introduction of SPARK, what 15 years ago now?) offers even more safety features that I've not seen in Rust, through the form of code contracts. Conttracts which can be used as run-time checks, and (to some degree) as static proofs about the code.

Extend Rust's type system and add a contract mechanism, then it'll have the same use-case that I have for Ada.

SPARK contracts look super interesting. It seems like that could let an optimizer do some great stuff and decrease the mental burden of reasoning about mostly pure functions by calling out specific side effects. What is different about its types? I don't see anything obvious. What I'd miss about rust is the borrowchecker and const by default.

Hmm on further investigation I think most of the use cases I'd have for contracts are met by the borrow checker. Side effects are going to get wrapped in unsafe or be explicit in the function signature.

I would recommend https://www.adacore.com/uploads/books/pdf/ePDF-Implementatio... for more information regarding contracts. There are of course a LOT more, just fire up your preferred search engine and enjoy your findings. :)

> SPARK builds on the strengths of Ada to provide even more guarantees statically rather than dynamically. As summarized in the following table, Ada provides strict syntax and strong typing at compile time plus dynamic checking of run-time errors and program contracts. SPARK allows such checking to be performed statically. In addition, it enforces the use of a safer language subset and detects data flow errors statically.

Contract programming:

- Ada: dynamic

- SPARK: dynamic / static

Run-time errors:

- Ada: dynamic

- SPARK: dynamic / static

Data flow errors:

- Ada: -

- SPARK: static

Strong typing:

- Ada: static

- SPARK: static

Safer language subset:

- Ada: -

- SPARK: static

Strict clear syntax:

- Ada: static

- SPARK: static

---

Additionally, safe pointers in SPARK: https://blog.adacore.com/using-pointers-in-spark and https://arxiv.org/abs/1710.07047.

---

Cryptographic library in SPARK 2014: https://github.com/Componolit/libsparkcrypto.

> libsparkcrypto is a formally verified implementation of several widely used cryptographic algorithms using the SPARK 2014 programming language and toolset. For the complete library proofs of the absence of run-time errors like type range violations, division by zero and numerical overflows are available. Some of its subprograms include proofs of partial correctness.

---

Ada/SPARK is excellent for real-time and safety-critical software: https://www.rcs.ei.tum.de/fileadmin/tueircs/www/becker/spark... to give you some ideas. It may be a bit outdated in some regards, though, for example: "Next version of SPARK 2014 under development (pointers!).". It is already done! :)

How?

Ada was designed for programming safety-critical, military-grade embedded systems.

Rust was designed as a memory-safe, concurrency-safe programming language, largely to overcome the shortcomings of C++.

Each excels at what it was designed for, but the intended use cases are very different.

Rust is not (currently) being used for aircraft flight control systems--Ada is.

Ada is not (currently) being used for high-performance web browsers and servers--Rust is.

While there are SOME similar design goals in terms of memory safety, concurrency safety, and error prevention, they do not "overlap almost entirely in use case".

Those are good points. While I can see rust flying within the next few years, I dont see it in flight controls for a while yet. That said I'm aware of c++ flight control software which seems insane. And that seems to be the trend. Rust does target embedded so there is no reason not to try and move it in that direction, though ada seems a much better choice.

Agreed. The PicoRV32 mentioned in the article's "WHERE TO GO FROM HERE" section has its own crate: https://docs.rs/picorv32/0.1.3/picorv32/

C/C++ have been great for embedded work, but Ada and Rust are better alternatives in my opinion. They are safer, more powerful, and more secure.