6 ms·

This is a very interesting move from AdaCore. I've been a vocal advocate of Ada as a general purpose programming language for a little while. I hope that this h

by ajxs 5y ago

This is a very interesting move from AdaCore. I've been a vocal advocate of Ada as a general purpose programming language for a little while. I hope that this helps expose the language to a wider audience, and gives the wider programming community cause to reappraise Ada from a modern perspective. It's a language with a lot to offer.

Argorak 5y ago
I very much agree. Rust is often seen as C/C++-inspired, but I know a lot of the early team looked at Ada for inspiration. We have also seen in many evaluations of "new stacks" that we were invited in that Ada was evaluated along with Rust. The conclusion was often similar: both languages have matching ambitions, in different forms. Also, there's a ton of places where Ada is just "there" already, e.g. by having something like SPARK available and in production use for many years. I expressed some of those thoughts in the corresponding post on the Ferrous Systems blog: https://ferrous-systems.com/blog/ferrous-systems-adacore-joining-forces/ https://ferrous-systems.com/blog/ferrous-systems-adacore-joi...
- zppln 5y ago
  I'm curious as to what you see are the benefits of using Rust in high assurance applications, compared to the alternatives already available? In my experience (which doesn't include anything related to formal verification), when everything's said and done you're left with a fairly limited subset of your chosen language anyway.
  - Argorak 5y ago
    Rust makes quite a few things more rigorous (e.g. pairing allocations with deallocations and reference validity). It basically fulfills the job of a static analyzer baked into the language. It's also a vastly more analyzable language (in that its syntax is reasonably unambiguous and there's no dynamic runtime in play) and it can be integrated well. Toolchain quality (error reporting, built in testing, awareness of primitives like "libraries", etc.) is also a huge strong point. We're reasonably confident that we can use safe Rust as is, with strong guidance on how to do unsafe Rust. For a tangible investigation of that space, PolySync has a project that has a look at MISRA rules from a Rust perspective. https://github.com/PolySync/misra-rust/blob/master/MISRA-Rules.md#misrac https://github.com/PolySync/misra-rust/blob/master/MISRA-Rul... Ada is a good example here: the language has not evolved something like MISRA-C (it has evolved SPARK for formal verification, but I see that differently).
    - zppln 5y ago
      Interesting, thanks. The reason I ask is that in my experience you don't malloc mid-flight so to speak (for WCET/WCRU reasons, among others), so Rust's guarantees there are largely irrelevant. It's a pretty opaque area of the software industry though, so others may have come to other conclusions.
      - steveklabnik 5y ago
        I'm not working in safety critical systems, but our embedded OS doesn't do any dynamic memory allocation at all, and Rust still helps quite a bit even without that. https://cliffle.com/blog/on-hubris-and-humility/ https://cliffle.com/blog/on-hubris-and-humility/
      - Argorak 5y ago
        DO-178C has writing and requirements around dynamic memory management. (DO-332 / ED-217, OO.D.1.6) Rust also can also model other things through ownership, like passing a device handle safely between components, to avoid concurrent use.
        zppln 5y ago
        Thanks, I wasn't aware of DO-332 actually. I'll have to see if it's available through work. It's always interesting to think about how things can be done differently and where the tradeoffs would be. :)
        Argorak 5y ago
        Feel free to reach out, it's a topic of interest to us. A good place to discuss is for example the AeroRust Discord or just send me an email. https://github.com/AeroRust/Welcome https://github.com/AeroRust/Welcome
      - mlindner 5y ago
        Rust has the same advantages in malloc-free environments as well. Dangling pointers can still be a thing in non-malloc code.
  - gameswithgo 5y ago
    Compared to most other languages that focus on correctness, Rust performs better. If you don't need performance, probably one of the other alternatives is better. However Rust may be unique in preventing data races at compile time, which could be a huge boon in some applications. I suppose languages like Haskell maybe accomplish that as well, since you never mutate state at all?
- mjw1007 5y ago
  Is there going to be an announcement on the current status of Ferrocene soon? It's been almost a year since the last blog post. In the meeting with the lang team last February, I think the consensus was that the next step would be to create a proposed charter for a project group. Did that happen?
  - Argorak 5y ago
    First question: yes. It was hard to talk about the current state of Ferrocene with all the things ongoing last year. Now that I have more bandwidth and we found a development beat, you can also expect more regular updates. Second question: that was the discussion about higher assurances in the compiler in general. The group did not form, but that's on the project side, where I'm not part of anymore. We're very ready to participate there though.
deleted 5y ago
[deleted]
pjmlp 5y ago
The folks from Ada Core have also been playing with affine types for Ada/Spark and the ParaSail author has joined them for a couple of years now. So it is really cool to see them working even closer with the Rust community.
- touisteur 5y ago
  They also have a deep experience in certification and high assurance norms, which makes them an interesting partner whenever you're entering a regulated market. Not something I make use of, but I see a lot of papers/books coming from there and had deep very interesting discussions about the whole software and system safety engineering process and trust-building.
  - pjmlp 5y ago
    Fully agree. I also occasionally read stuff on high integrity computing, very interesting material that the industry at large still is far behind of what could be in practice.
hyperman1 5y ago
I think the visual style of the language rubs off. There is for example C-like: Curly brackets, small keyword count, etc ... This is a language for people who want to write fast code that gets things done, not a gram of weight too much. Hacker spirit. Python-like: Indentation. A bit more keywords. This is a language that wants to be clear, beautiful, abstract, communicating to other readers. Academic spirit. Cobol-like: A huge wall of text. Lots of Divisions and Organization. Bureaucratic, smells of meetings, punch cards and months of delay. Enterprise spirit. Ada, unfortunately, looks cobol-like, so someone who knows nothing automatically assumes a ton of bureaucracy. Run away if you want work done. Note this is purely cosmetic and has nothing to do with actual language quality.
- touisteur 5y ago
  Strangely, Ada, while aimed for large-scale developments (hence the 'bureaucratic' feeling?) since conception, puts a heavy weight on readability and maintainability. No implicit shortcut operators, words instead of symbols, specific block markers (for loops, ifs, lexical block, embedded functions, ...) and explicit generic instantiation. Can be a pain to write, but it's really easier for me (whose days consist mostly of Ada, java, python, C++, C - don't ask - coding and reading) to read.
  - gavinray 5y ago
    A lot of this has been much-improved with Ada 2022 and recent changes. Notably, lambdas, pattern matching, less-verbose operators, etc. https://blog.adacore.com/going-beyond-ada-2022 https://blog.adacore.com/going-beyond-ada-2022
    - touisteur 5y ago
      You say 'improved' but I feel it doesn't always go the 'more readable' way. I'm very much not a fan of the 'dot notation' and still like to use named parameters, and force explicit types instead of the creeping auto trend. I read much more code than I write and I'm feeling... not heard on the recent changes to ease code writing. At least I can write libadalang scripts (or langserv one day 'to right-click add back what I need in for-of loops, or dot-notation.

by ajxs 5y ago

Argorak 5y ago

I very much agree. Rust is often seen as C/C++-inspired, but I know a lot of the early team looked at Ada for inspiration. We have also seen in many evaluations of "new stacks" that we were invited in that Ada was evaluated along with Rust. The conclusion was often similar: both languages have matching ambitions, in different forms. Also, there's a ton of places where Ada is just "there" already, e.g. by having something like SPARK available and in production use for many years. I expressed some of those thoughts in the corresponding post on the Ferrous Systems blog: https://ferrous-systems.com/blog/ferrous-systems-adacore-joining-forces/ https://ferrous-systems.com/blog/ferrous-systems-adacore-joi...

zppln 5y ago
I'm curious as to what you see are the benefits of using Rust in high assurance applications, compared to the alternatives already available? In my experience (which doesn't include anything related to formal verification), when everything's said and done you're left with a fairly limited subset of your chosen language anyway.
- Argorak 5y ago
  Rust makes quite a few things more rigorous (e.g. pairing allocations with deallocations and reference validity). It basically fulfills the job of a static analyzer baked into the language. It's also a vastly more analyzable language (in that its syntax is reasonably unambiguous and there's no dynamic runtime in play) and it can be integrated well. Toolchain quality (error reporting, built in testing, awareness of primitives like "libraries", etc.) is also a huge strong point. We're reasonably confident that we can use safe Rust as is, with strong guidance on how to do unsafe Rust. For a tangible investigation of that space, PolySync has a project that has a look at MISRA rules from a Rust perspective. https://github.com/PolySync/misra-rust/blob/master/MISRA-Rules.md#misrac https://github.com/PolySync/misra-rust/blob/master/MISRA-Rul... Ada is a good example here: the language has not evolved something like MISRA-C (it has evolved SPARK for formal verification, but I see that differently).
  - zppln 5y ago
    Interesting, thanks. The reason I ask is that in my experience you don't malloc mid-flight so to speak (for WCET/WCRU reasons, among others), so Rust's guarantees there are largely irrelevant. It's a pretty opaque area of the software industry though, so others may have come to other conclusions.
    - steveklabnik 5y ago
      I'm not working in safety critical systems, but our embedded OS doesn't do any dynamic memory allocation at all, and Rust still helps quite a bit even without that. https://cliffle.com/blog/on-hubris-and-humility/ https://cliffle.com/blog/on-hubris-and-humility/
    - Argorak 5y ago
      DO-178C has writing and requirements around dynamic memory management. (DO-332 / ED-217, OO.D.1.6) Rust also can also model other things through ownership, like passing a device handle safely between components, to avoid concurrent use.
      - zppln 5y ago
        Thanks, I wasn't aware of DO-332 actually. I'll have to see if it's available through work. It's always interesting to think about how things can be done differently and where the tradeoffs would be. :)
        Argorak 5y ago
        Feel free to reach out, it's a topic of interest to us. A good place to discuss is for example the AeroRust Discord or just send me an email. https://github.com/AeroRust/Welcome https://github.com/AeroRust/Welcome
    - mlindner 5y ago
      Rust has the same advantages in malloc-free environments as well. Dangling pointers can still be a thing in non-malloc code.
- gameswithgo 5y ago
  Compared to most other languages that focus on correctness, Rust performs better. If you don't need performance, probably one of the other alternatives is better. However Rust may be unique in preventing data races at compile time, which could be a huge boon in some applications. I suppose languages like Haskell maybe accomplish that as well, since you never mutate state at all?
mjw1007 5y ago
Is there going to be an announcement on the current status of Ferrocene soon? It's been almost a year since the last blog post. In the meeting with the lang team last February, I think the consensus was that the next step would be to create a proposed charter for a project group. Did that happen?
- Argorak 5y ago
  First question: yes. It was hard to talk about the current state of Ferrocene with all the things ongoing last year. Now that I have more bandwidth and we found a development beat, you can also expect more regular updates. Second question: that was the discussion about higher assurances in the compiler in general. The group did not form, but that's on the project side, where I'm not part of anymore. We're very ready to participate there though.

deleted 5y ago

[deleted]

pjmlp 5y ago

The folks from Ada Core have also been playing with affine types for Ada/Spark and the ParaSail author has joined them for a couple of years now. So it is really cool to see them working even closer with the Rust community.

touisteur 5y ago
They also have a deep experience in certification and high assurance norms, which makes them an interesting partner whenever you're entering a regulated market. Not something I make use of, but I see a lot of papers/books coming from there and had deep very interesting discussions about the whole software and system safety engineering process and trust-building.
- pjmlp 5y ago
  Fully agree. I also occasionally read stuff on high integrity computing, very interesting material that the industry at large still is far behind of what could be in practice.

hyperman1 5y ago

I think the visual style of the language rubs off. There is for example C-like: Curly brackets, small keyword count, etc ... This is a language for people who want to write fast code that gets things done, not a gram of weight too much. Hacker spirit. Python-like: Indentation. A bit more keywords. This is a language that wants to be clear, beautiful, abstract, communicating to other readers. Academic spirit. Cobol-like: A huge wall of text. Lots of Divisions and Organization. Bureaucratic, smells of meetings, punch cards and months of delay. Enterprise spirit. Ada, unfortunately, looks cobol-like, so someone who knows nothing automatically assumes a ton of bureaucracy. Run away if you want work done. Note this is purely cosmetic and has nothing to do with actual language quality.

touisteur 5y ago
Strangely, Ada, while aimed for large-scale developments (hence the 'bureaucratic' feeling?) since conception, puts a heavy weight on readability and maintainability. No implicit shortcut operators, words instead of symbols, specific block markers (for loops, ifs, lexical block, embedded functions, ...) and explicit generic instantiation. Can be a pain to write, but it's really easier for me (whose days consist mostly of Ada, java, python, C++, C - don't ask - coding and reading) to read.
- gavinray 5y ago
  A lot of this has been much-improved with Ada 2022 and recent changes. Notably, lambdas, pattern matching, less-verbose operators, etc. https://blog.adacore.com/going-beyond-ada-2022 https://blog.adacore.com/going-beyond-ada-2022
  - touisteur 5y ago
    You say 'improved' but I feel it doesn't always go the 'more readable' way. I'm very much not a fan of the 'dot notation' and still like to use named parameters, and force explicit types instead of the creeping auto trend. I read much more code than I write and I'm feeling... not heard on the recent changes to ease code writing. At least I can write libadalang scripts (or langserv one day 'to right-click add back what I need in for-of loops, or dot-notation.