Hacker News new | ask | show | jobs
by ajxs 1603 days 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.
3 comments

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

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

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

This may interest you: "In this document, we show how SPARK can be used to achieve high code quality with guarantees that go beyond what would be feasible with MISRA C."

https://www.adacore.com/uploads/books/pdf/SPARK-Ada-for-MISR...

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

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.

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. :)
Rust has the same advantages in malloc-free environments as well. Dangling pointers can still be a thing in non-malloc code.
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?

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?

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.

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.

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

Sorry, but I disagree. Maybe in the 80s when developers were all yelling while coding :p Does this look like cobol to you?

   type GUID_String is new String (1 .. 32)
     with Dynamic_Predicate => (for all C of GUID_String => C in '0' .. '9' | 'a' .. 'f');
The only thing Ada has in common with cobol is that you can define decimal fixed point types (you specify the number of digits and a delta, which must be a power of 10) [1]

I usually use ordinary fixed point types:

   type Axis_Position is delta 2.0 ** (-15) range -1.0 .. 1.0 - 2.0 ** (-15)
     with Size => 16;
or (from wayland-ada [2]):

   type Fixed is delta 2.0 ** (-8) range -(2.0 ** 23) .. +(2.0 ** 23 - 1.0)
     with Small => 2.0 ** (-8),
          Size  => Integer'Size;
[1] https://en.wikibooks.org/wiki/Ada_Programming/Types/delta#Di... [2] https://github.com/onox/wayland-ada
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.
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

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.
> Ada, unfortunately, looks cobol-like, so someone who knows nothing automatically assumes a ton of bureaucracy. Run away if you want work done.

Ada looks nothing like COBOL., except perhaps in the most superficial sense (a bit keyword heavy compared to most other languages). The syntactic structure is really not far from what people are familiar with, in sharp contrast to COBOL. Rosettacode is a good site if you want to find some interesting (small) comparisons between languages. This is from the GCD page:

The COBOL version:

  IDENTIFICATION DIVISION.
  PROGRAM-ID. GCD.
 
  DATA DIVISION.
  WORKING-STORAGE SECTION.
  01 A        PIC 9(10)   VALUE ZEROES.
  01 B        PIC 9(10)   VALUE ZEROES.
  01 TEMP     PIC 9(10)   VALUE ZEROES.
 
  PROCEDURE DIVISION.
  Begin.
      DISPLAY "Enter first number, max 10 digits."
      ACCEPT A
      DISPLAY "Enter second number, max 10 digits."
      ACCEPT B
      IF A < B
        MOVE B TO TEMP
        MOVE A TO B
        MOVE TEMP TO B
      END-IF
 
      PERFORM UNTIL B = 0
        MOVE A TO TEMP
        MOVE B TO A
        DIVIDE TEMP BY B GIVING TEMP REMAINDER B
      END-PERFORM
      DISPLAY "The gcd is " A
      STOP RUN.
The Ada version:

   function Gcd (A, B : Integer) return Integer is
      M : Integer := A;
      N : Integer := B;
      T : Integer;
   begin
      while N /= 0 loop
         T := M;
         M := N;
         N := T mod N;
      end loop;
      return M;
   end Gcd;
The C version on that page demonstrates what I'd consider a bad practice, but I'll show it and how a clearer version might be written:

  static int gcd(int a, int b)
  {
    while (b != 0) b = a % (a = b); // not clear at all, good way to avoid a temporary variable
    return a;
  }
  static int gcd(int a, int b)
    int t;
    while (b != 0) {
      t = b;
      b = a % b;
      a = b;
    }
    return a;
  }
Compared to Ada, that second C one is 3 lines shorter, which corresponds to the lack of `begin` and reusing the parameter variables rather than defining two new local variables for the loop. Ada doesn't permit you to assign to "in" parameters, which is the default.

http://rosettacode.org/wiki/Greatest_common_divisor

This is one of those post where I'm happy to see so much people disagreeing, except I'm not sure we're disagreeing. Your key sentence is: ... except in the most superficial sense... That is exactly the barrier Ada needs to overcome. If people take the time to really look at Ada,they'd see its actually quite reasonable.

But if someone asks what language to learn, they start with shortening the almost infinite list of languages to something worth looking at. This filtering process happens in the crudest possible way, based more on feelings and hearsay than on verified facts: How big is the ecosystem, how will other people look at my code, ... This proces delivers, say, about 10 to 20 languages worth actually spending time looking at them. That's the hurdle Ada has to jump. This is a marketing problem.

If you look at rust, the work done by Mozilla and people like e.g. Steve Klabnik to put the language on the map is enourmously valuable. With code examples, blog post, fixing real world pain points, answering questions, .... It took years but they did it. If Ada had a group of people and a bigname organization, all doing this work, it would be a completely different story.

I'm disagreeing with the assertion that Ada looks like COBOL. You may or may not agree with that statement, but you made it.

> This filtering process happens in the crudest possible way, based more on feelings and hearsay than on verified facts

And that's why people should stop making statements like:

>>> Ada, unfortunately, looks cobol-like, so someone who knows nothing automatically assumes a ton of bureaucracy. Run away if you want work done.

Without much stronger caveats to clarify that it is not a correct impression. Without a strong statement clarifying that it's only an impression (based on the most superficial of analyses) and not the reality, people will read comments like yours (and others in threads like this one) and never go any further to realize that they're false, and end up repeating them.

In an Ada thread just a few weeks back someone wrote COBOL-ish code claiming it was Ada code. It was a math-y example like the GCD code above, and clearly wouldn't work if you had even a passing familiarity with Ada. But it was written in such strong terms that it gave the impression the author was competent when they were really ignorant.

> If you look at rust, the work done by Mozilla and people like e.g. Steve Klabnik to put the language on the map is enourmously valuable. With code examples, blog post, fixing real world pain points, answering questions, .... It took years but they did it. If Ada had a group of people and a bigname organization, all doing this work, it would be a completely different story.

AdaCore has actually done a lot of the same.

http://learn.adacore.com - really good learning resources, freely available

https://blog.adacore.com - active blog describing various Ada-based projects as well as developments in SPARK and Ada.

And as an answer to things like Cargo there's now Alire:

https://alire.ada.dev

Both comp.lang.ada and r/ada are pretty active.

Agreed, but the problem you're describing has nothing to do with looking like COBOL. If we're talking superficial syntax, my first thought was that it looks like Ruby but with C++-style interface/implementation separation. The syntax is odd, but not at all unpleasant.

For me, my hurdles were:

* First, I thought that Ada was exclusively a proprietary language.

* Then, I got confused about whether I can use GNAT Community and not publish it under the GPL (https://www.adacore.com/get-started says I must).

* Finally I found FSF GNAT (http://www.getadanow.com/), so it turns out there is a standard-licensed language I can use.

At this point I'm finally ready to actually try Ada, and just haven't started a project that seemed like a good fit. But the bulk of my barrier to entry was licensing questions, not syntax.

Yep! This is the tutorial that finally cleared everything up for me. I'd previously found AdaCore.com, which was where I learned about the Community edition but not the FSF GNAT.
You can use any version of gnat to build this - https://github.com/Lucretia/sdlada
> That is exactly the barrier Ada needs to overcome

No, this is the barrier people need to overcome. Readable is good.

It's kind of the opposite for me. It takes much less time to understand what Ada-written code is doing compared to any of the C-type languages, or even Rust. It is very plainly written. Verbose, yes, but much more plainly written.

Just take a look at this, and tell me it's not legible: https://github.com/joakim-strandberg/advent_of_code/blob/mas...

The Pascal family could benefit by a bit more of brevity, but I trade the syntax of it to C-like langs like Rust any day. They are not that less verbose at the end: Is only in the "small" that look compact.
Yeah, not bad.

Another one, because look like you are looking for inspiration:

https://www.elementscompiler.com/elements/oxygene/language.a...

Yeah, I remember seeing that years ago, shame it's not open and only win/mac.
> Ada, unfortunately, looks cobol-like, so someone who knows nothing automatically assumes a ton of bureaucracy. Run away if you want work done.

The Ada++ project (a modified GNAT compiler) might interest you then.

http://www.adapplang.com/

Have you had a release since last April 1st? Or fixed the ugly case statement?

  case Variable: -- <====
    when 0      => Put_Line ("Zero");
    when 1 .. 9 => Put_Line ("Positive Digit");
    when 10 | 12 | 14 | 16 | 18 =>
      Put_Line ("Even Number between 10 and 18");
    when others => Put_Line ("Something else");
  } -- <====
Matching : with } does not make for clearer code.
What other suggestions do you have besides changes to the case statements?
Ada++ makes two changes to the Ada language. First, it changes some keywords into new keywords or symbols, but in a gross way (the case example, is becomes : as a blanket rule, even when it leads to : being paired with }). This could be done by a (tedious) awk program or sed script. The second change it makes is that use will also with a package, that's a nice ergonomic feature. But it's the only thing of modest complexity that it does to change the language. There are no other enhancements to the language that it introduces that make it a compelling thing or an obvious non-joke (it's release date for 0.2.0 was 1 April 2021).

The actual Ada developers are focused on actual language enhancements with the Ada 2022 standard and increasing the scope of properties that SPARK (a proper subset of Ada now) can prove about a program. Including approaching some of the properties that people find desirable with Rust's borrow checker and lifetime analysis. Ada++ should be doing things like that, meaningfully improving the language and not just being a glorified awk program that doesn't change or add any real syntactic or semantic properties of the language. Also, the author should stop doing releases on April Fool's Day if they really want to be taken seriously.

It is an April Fools Day joke. They forked GCC and made one commit on April Fools Day 2021, and haven't touched it sense.

Compare:

Ada++ -- https://github.com/AdaPlusPlus/gcc/commits/master

GCC 10 (history from April 2021) -- https://github.com/gcc-mirror/gcc/commits/releases/gcc-10?af...