6 ms·

First, this is a great introduction article to Ada. It's a great history lesson, and analysis of where it's used and why. That said, it seems to be arguing for

First, this is a great introduction article to Ada. It's a great history lesson, and analysis of where it's used and why. That said, it seems to be arguing for something in a vacuum. Where is the mention of other new programming languages that also fit this category? Where is the mention of Rust? Rust fits all the same requirements: - A general, flexible design that adapts to satisfy the needs of embedded computer applications. - Reliability. The language should aid the design and development of reliable programs. - Ease of maintainability. Code should be readable and programming decisions explicit. - Easy to produce efficient code with. Inefficient constructs should be easily identifiable. - No unnecessary complexity. Semantic structure should be consistent and minimize the number of concepts. - Easy to implement the language specification. All features should be easy to understand. - Machine independence. The language shall not be bound to any hardware or OS details. - Complete definition. All parts of the language shall be fully and unambiguously defined. The exception is possibly the last one, complete definition. But that's debatable as Rust does have a reference, but no one wants to go as far as calling it a spec. (Also, I know some people think Rust has some "unnecessary" complexity, personally I do not). The article goes on to compare to C, but doesn't mention some of the new features of C++ that make it safer, or Rust which is approximately as safe as Ada. So why would I pick Ada over other modern languages? btw, I really enjoyed Steve Klabnik's post on learning Ada: https://words.steveklabnik.com/learning-ada https://words.steveklabnik.com/learning-ada

falcolas 7y ago
> - 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.
- swsieber 7y ago
  > 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.
  - falcolas 7y ago
    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.
    - swsieber 7y ago
      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.
- vardump 7y ago
  > ...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.
  - otabdeveloper2 7y ago
okl 7y ago
> 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.
- JoshTriplett 7y ago
  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.
  - blub 7y ago
    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.
    - bluejekyll 7y ago
      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.
im_down_w_otp 7y ago
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.
- steveklabnik 7y ago
  > 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/ https://ferrous-systems.com/blog/sealed-rust-the-pitch/ There's still a lot of interest; this stuff doesn't happen quickly.
  - im_down_w_otp 7y ago
    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.
    - steveklabnik 7y ago
      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.
59nadir 7y ago
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.
- vardump 7y ago
  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.
  - flavio81 7y ago
    >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
    - kelnos 7y ago
      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.
      - Apocryphon 7y ago
        Go?
      - pjmlp 7y ago
        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.
fortran77 7y ago
Why can't someone write an article about Ada without it having to be about Rust?
- galangalalgol 7y ago
  Because they overlap almost entiely in use case?
  - Jtsummers 7y ago
    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.
    - galangalalgol 7y ago
      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.
    - galangalalgol 7y ago
      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.
    - johnisgood 7y ago
      I would recommend https://www.adacore.com/uploads/books/pdf/ePDF-ImplementationGuidanceSPARK.pdf 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 https://blog.adacore.com/using-pointers-in-spark and https://arxiv.org/abs/1710.07047 https://arxiv.org/abs/1710.07047. --- Cryptographic library in SPARK 2014: https://github.com/Componolit/libsparkcrypto 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/spark2014-intro.pdf 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! :)
johnisgood 7y ago
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/ https://www.fstar-lang.org/
- lone_haxx0r 7y ago
  And the "worst name" prize goes to ...
  - OneWingedShark 7y ago
    Go. Still Go.

falcolas 7y ago

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

swsieber 7y ago
> 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.
- falcolas 7y ago
  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.
  - swsieber 7y ago
    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.
vardump 7y ago
> ...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.
- otabdeveloper2 7y ago

okl 7y ago

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

JoshTriplett 7y ago
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.
- blub 7y ago
  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.
  - bluejekyll 7y ago
    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.

im_down_w_otp 7y ago

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.

steveklabnik 7y ago
> 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/ https://ferrous-systems.com/blog/sealed-rust-the-pitch/ There's still a lot of interest; this stuff doesn't happen quickly.
- im_down_w_otp 7y ago
  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.
  - steveklabnik 7y ago
    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.

59nadir 7y ago

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.

vardump 7y ago
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.
- flavio81 7y ago
  >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
  - kelnos 7y ago
    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.
    - Apocryphon 7y ago
      Go?
    - pjmlp 7y ago
      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.

fortran77 7y ago

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

galangalalgol 7y ago
Because they overlap almost entiely in use case?
- Jtsummers 7y ago
  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.
  - galangalalgol 7y ago
    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.
  - galangalalgol 7y ago
    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.
  - johnisgood 7y ago
    I would recommend https://www.adacore.com/uploads/books/pdf/ePDF-ImplementationGuidanceSPARK.pdf 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 https://blog.adacore.com/using-pointers-in-spark and https://arxiv.org/abs/1710.07047 https://arxiv.org/abs/1710.07047. --- Cryptographic library in SPARK 2014: https://github.com/Componolit/libsparkcrypto 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/spark2014-intro.pdf 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! :)

johnisgood 7y ago

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/ https://www.fstar-lang.org/

lone_haxx0r 7y ago
And the "worst name" prize goes to ...
- OneWingedShark 7y ago
  Go. Still Go.