Adacore joins with Ferrous Systems to support Rust

Adacore joins with Ferrous Systems to support Rust

[Paul Rubin]

https://blog.adacore.com/adacore-and-ferrous-systems-joining-forces-to-support-rust

Ferrous Systems is apparently a Rust support company based in Germany.
From the linked page:

    "Ferrous Systems and AdaCore are announcing today that they’re
    joining forces to develop Ferrocene - a safety-qualified Rust
    toolchain, which is aimed at supporting the needs of various
    regulated markets, such as automotive, avionics, space, and
    railway."

No mention about whether there will be any type of FOSS or community
release.  No word on whether the compiler and/or toolchain will be based
on the existing stuff, or something new.  Wonder how they will
safety-certify anything in Rust when the language itself doesn't even
have a formal spec.  But, it is an interesting development.

Is the writing on the wall for Ada?

Re: Adacore joins with Ferrous Systems to support Rust

[Luke A. Guest]

On 02/02/2022 08:57, Paul Rubin wrote:
> https://blog.adacore.com/adacore-and-ferrous-systems-joining-forces-to-support-rust
> 
> Ferrous Systems is apparently a Rust support company based in Germany.
>  From the linked page:
> 
>      "Ferrous Systems and AdaCore are announcing today that they’re
>      joining forces to develop Ferrocene - a safety-qualified Rust
>      toolchain, which is aimed at supporting the needs of various
>      regulated markets, such as automotive, avionics, space, and
>      railway."
> 
> No mention about whether there will be any type of FOSS or community
> release.  No word on whether the compiler and/or toolchain will be based
> on the existing stuff, or something new.  Wonder how they will
> safety-certify anything in Rust when the language itself doesn't even
> have a formal spec.  But, it is an interesting development.
> 
> Is the writing on the wall for Ada?

I see this going one way, Ada loses out as the Rust side uses AdaCore to 
get what they want.

Re: Adacore joins with Ferrous Systems to support Rust

[Marius Amado-Alves]

If possible please tell what Rust has to offer over Ada.
From a quick look at the Rust book it seemed weaker in structured programming, generic programming, type system.
Thanks.

Re: Adacore joins with Ferrous Systems to support Rust

[Luke A. Guest]

On 02/02/2022 15:29, Marius Amado-Alves wrote:
> If possible please tell what Rust has to offer over Ada.
>  From a quick look at the Rust book it seemed weaker in structured programming, generic programming, type system.
> Thanks.

Don't know why you're asking me, but to me, not a lot, only the borrow 
checker stuff.

Re: Adacore joins with Ferrous Systems to support Rust

[Stephen Leake]

"Luke A. Guest" <laguest@archeia.com> writes:

> On 02/02/2022 15:29, Marius Amado-Alves wrote:
>> If possible please tell what Rust has to offer over Ada.
>>  From a quick look at the Rust book it seemed weaker in structured
>> programming, generic programming, type system.
>> Thanks.
>
> Don't know why you're asking me, but to me, not a lot, only the borrow
> checker stuff.

Which Ada now has in SPARK (or will soon, at least in GNAT).

-- 
-- Stephe

Re: Adacore joins with Ferrous Systems to support Rust

[Rene]

Am 02.02.22 um 17:36 schrieb Luke A. Guest:
> On 02/02/2022 15:29, Marius Amado-Alves wrote:
>> If possible please tell what Rust has to offer over Ada.
>>  From a quick look at the Rust book it seemed weaker in structured 
>> programming, generic programming, type system.
>> Thanks.
> 
> Don't know why you're asking me, but to me, not a lot, only the borrow 
> checker stuff.
> 

Don't forget the curly brackets.

Re: Adacore joins with Ferrous Systems to support Rust

[G.B.]

On 02.02.22 16:29, Marius Amado-Alves wrote:
> If possible please tell what Rust has to offer over Ada.
>  From a quick look at the Rust book it seemed weaker in structured programming, generic programming, type system.
> Thanks.

Embedded systems reportedly still mostly use C.
Consequently, C is the thing to which a language's merits must
be compared. If Rust managers manage to persuade C shops
to use Rust, the this is a reasonable attempt at improving C based
program production. If Ada influence the process, then
it has had a purpose. :-)

Perhaps it is easier to add guarantees to Rust programs
than to C programs. Also, C programmers might feel more
at home when using Rust. Java programmers also, even when
it is just curly braces.

Re: Adacore joins with Ferrous Systems to support Rust

[John McCabe]

On Wednesday, 2 February 2022 at 15:29:13 UTC, amado...@gmail.com wrote:
> If possible please tell what Rust has to offer over Ada. 

A very nasty syntax, and there's an annoying thing where it moans about what you've called your project.

TBH that's about as far as I got with Rust; I can't be doing with pedantic restrictions that have no technical benefit (as far as I can see). 

Re: Adacore joins with Ferrous Systems to support Rust

[amo...@unizar.es]

On Wednesday, February 2, 2022 at 4:29:13 PM UTC+1, amado...@gmail.com wrote:
> If possible please tell what Rust has to offer over Ada. 

In my minimally informed opinion after going through parts of the official tutorial a couple of times, what Rust has to offer in general:

+ Memory safety (no leaks, double-free, race conditions*) by default.
- Terrible illegible syntax
+ Safer/more expressive/more modern constructs than C
+ Modern tooling shared by all the community

[*] I guess in a protected-object sense, not in a high-level logic sense. But I don't really know.

The thing is that C is so basic and C++ so prone to shooting yourself in the foot, that Rust hits a middle ground that feels like the best thing since sliced bread to C/C++ programmers wishing for something better. Add to that the true novel contribution to a mainstream language that is memory safety (this is really a new way of thinking when you get into Rust), that if you don't know better (e.g., Ada) it really is overwhelmingly compelling. I'm not surprised at the cult-like following (I mean, we feel like that sometimes in the Ada world, right?) In a sense, Rust is the Ada of a younger generation, and without the baggage.

Of course you sometimes have to use "unsafe" programming evading the borrow checker, just like pointers are sometimes a necessity in Ada; and the legibility becomes truly awful IMHO really fast (to me, this is THE Achilles heel nobody seems to care too much about), but as I said, it has a couple of real selling points over the competition. Of course, if legibility is not your concern because you're used to C++ templating nightmares, you don't feel that particular pain. It's always the same story with Ada; most people don't know better to realize what they're missing.

The whole memory safety thing with the borrow checker goes beyond a gimmick, and it has a solid quality which goes beyond "in Ada you don't need pointers most of the time". It's a compile-time check, and it makes evident that runtime checks are a poor substitute. I'm more ashamed now of the whole anonymous pointers and accessibility surprises in Ada. Yes, SPARK added something similar for pointers, but in Rust it is for all variables. The equivalence in Ada would be not being able to use the same variable in two consecutive calls as an in-out parameter. So it's not the same, besides being only in SPARK.

Not having done anything of real import, I'm not sure how inevitable it is to go unsafe in Rust. My guess is that it will be hidden in libraries just like the Ada standard containers contain some scary pointer use (and I mean that I wouldn't like to have to understand what is going there with the tampering checks etc.) At that point, obviously, you've lost the most solid selling point IMHO. Ada is safer not in a single sense, but as a whole design.

All in all, Rust has one big thing that Ada hasn't, which is the borrow checker.

And that is what how I would summarize it: Rust is better in a single narrow sense, but Ada is better as a general language. Which is, not surprisingly, the consequence of the design motivations for each, which were precisely to have a memory-safe language and a high-integrity-oriented language. So the funny thing is that both have succeeded at their objective.

I really miss not having the time to become proficient in Rust at least to be able to properly compare. I think the memory safety is great to have (and if Ada were designed today, I guess it should play the same integral part, if practical), but Rust is demanding on the programmer in a way that C/C++ aren't, and the maintainability seems suspect, so I don't know how far it will carry Rust into the future. I guess it could absorb a big part of both new C and C++ development.

Boy, can I write a lot sometimes...

Re: Adacore joins with Ferrous Systems to support Rust

[Luke A. Guest]

On 11/02/2022 17:40, amo...@unizar.es wrote:
> On Wednesday, February 2, 2022 at 4:29:13 PM UTC+1, amado...@gmail.com wrote:
>> If possible please tell what Rust has to offer over Ada.
> 
> In my minimally informed opinion after going through parts of the official tutorial a couple of times, what Rust has to offer in general:
> 
> + Memory safety (no leaks, double-free, race conditions*) by default.
> - Terrible illegible syntax
> + Safer/more expressive/more modern constructs than C
> + Modern tooling shared by all the community
> 
> [*] I guess in a protected-object sense, not in a high-level logic sense. But I don't really know.
> 
> The thing is that C is so basic and C++ so prone to shooting yourself in the foot, that Rust hits a middle ground that feels 

I'd say C++ is like a "backgun" (search images).

> like the best thing since sliced bread to C/C++ programmers wishing for something better. Add to that the true novel contribution to a mainstream language that is memory safety (this is really a new way of thinking when you get into Rust), that if you don't know better (e.g., Ada) it really is overwhelmingly compelling. I'm not surprised at the cult-like following (I mean, we feel like that sometimes in the Ada world, right?) In a sense, Rust is the Ada of a younger generation, and without the baggage.

Exactly, people want something better, but for some reason CAN NOT 
accept anything that doesn't look like C/C++.

> Of course you sometimes have to use "unsafe" programming evading the borrow checker, just like pointers are sometimes a necessity in Ada; and the legibility becomes truly awful IMHO really fast (to me, this is THE Achilles heel nobody seems to care too much about), but as I said, it has a couple of real selling points over the competition. Of course, if legibility is not your concern because you're used to C++ templating nightmares, you don't feel that particular pain. It's always the same story with Ada; most people don't know better to realize what they're missing.

And refuse to look for better, just accepting to continue using the same 
old, same old.

> The whole memory safety thing with the borrow checker goes beyond a gimmick, and it has a solid quality which goes beyond "in Ada you don't need pointers most of the time". It's a compile-time check, and it makes evident that runtime checks are a poor substitute.

So, you'd prefer, if Ada was designed now, it didn't do runtime checks 
(on pointers) and have compile-time checks?

> I'm more ashamed now of the whole anonymous pointers and accessibility surprises in Ada.

I'm not sure what you mean here.

> Yes, SPARK added something similar for pointers, but in Rust it is for all variables. The equivalence in Ada would be not being able to use the same variable in two consecutive calls as an in-out parameter. So it's not the same, besides being only in SPARK.

They added memory tracking at gnatprove time, much like the borrow 
checker afaik, which is an additional step.

> Not having done anything of real import, I'm not sure how inevitable it is to go unsafe in Rust. My guess is that it will be hidden in libraries just like the Ada standard containers contain some scary pointer use (and I mean that I wouldn't like to have to understand what is going there with the tampering checks etc.) At that point, obviously, you've lost the most solid selling point IMHO. Ada is safer not in a single sense, but as a whole design.

As soon as you hit the outside world, i.e. interfacing to other, lesser, 
languages or doing anything where memory has to be allocated, you need 
unsafe features.

> All in all, Rust has one big thing that Ada hasn't, which is the borrow checker.

I've not learnt any rust yet and that is my conclusion from what I've 
read. I need to do some tutorials at some point, but I also need eye bleach.

> And that is what how I would summarize it: Rust is better in a single narrow sense, but Ada is better as a general language. Which is, not surprisingly, the consequence of the design motivations for each, which were precisely to have a memory-safe language and a high-integrity-oriented language. So the funny thing is that both have succeeded at their objective.
> 
> I really miss not having the time to become proficient in Rust at least to be able to properly compare. I think the memory safety is great to have (and if Ada were designed today, I guess it should play the same integral part, if practical), but Rust is demanding on the programmer in a way that C/C++ aren't, and the maintainability seems suspect, so I don't know how far it will carry Rust into the future. I guess it could absorb a big part of both new C and C++ development.

I think the best way to really know a language better is to pick a 
single project and implement it in that language, something which is 
generally not trivial, but not too time consuming.

I do want to experiment when I get back to my compiler project.

> Boy, can I write a lot sometimes...

That's not a lot, I didn't refuse to read it.

Re: Adacore joins with Ferrous Systems to support Rust

[Alejandro R. Mosteo]

I'm sorry if this pops up twice, something strange happened with my 
first attempt.

On Fri, Feb 11, 2022 at 8:24 PM 'Luke A. Guest' wrote:
 > So, you'd prefer, if Ada was designed now, it didn't do runtime check 
(on pointers) and have compile-time checks?

I'd prefer that, as much as feasible, checks were moved (not removed!) 
to compile-time, yes. I know there are efforts in this direction at
AdaCore to simplify the accessibility checks model.

 > I'm more ashamed now of the whole anonymous pointers and 
accessibility surprises in Ada.
I'm not sure what you mean here.

My problem with runtime checks (which are undoubtedly better than no 
checks, sure), and in particular with accessibility checks, is that 
sometimes you get a failure much later during testing. By that time, 
understanding the problem may be 1) hard and 2) require painful 
redesign. At compile-time you get to deal with the problem immediately.

This is something in which Rust and Ada share the sentiment: "if it 
compiles, it works". So having something in another language found at 
compile-time makes me want to have it also in Ada at compile-time. It 
really spoils you against runtime checks. Much like I prefer the static 
elaboration model in GNAT instead of the dynamic one.

Also there are times in Ada where static checks are false positives that 
require some 'Unchecked_Access, and other times there is no failure yet 
you're doing something wrong. I find these from time to time in pretty 
obscure combinations not easy to provide a reproducer and frankly, I 
hate it. I'm never sure if I'm at fault, the compiler is at fault, or 
I've hit a corner case in the "heart of darkness". Nowadays I won't use 
a pointer even if it means obscene underperformance, until the thing is 
unavoidable.

There are also situations in which marking a parameter as aliased, even 
if you know it is already by reference (a limited/tagged type), will 
alter the things you can do with 'Access/'Unchecked_Access. There have 
been a couple of recent posts about that. Even if it's my fault, I find 
too hard to repeatably remember the finer details.

Re: Adacore joins with Ferrous Systems to support Rust

[John Perry]

> I really miss not having the time to become proficient in Rust at least to be able to properly compare.

I've followed this thread with some interest. I've had to learn & use Rust at work; it has its ups and downs.

> In my minimally informed opinion after going through parts of the official tutorial a couple of times, what Rust has to offer in general: 
> 
> + Memory safety (no leaks, double-free, race conditions*) by default. 
> ...
> [*] I guess in a protected-object sense, not in a high-level logic sense. But I don't really know. 

Here's what Rust promises: https://doc.rust-lang.org/nomicon/races.html

"Safe Rust guarantees an absence of data races, which are defined as... [omitted] Rust does not prevent general race conditions. This is pretty fundamentally impossible, and probably honestly undesirable. ... So it's perfectly "fine" for a Safe Rust program to get deadlocked or do something nonsensical with incorrect synchronization. ... Still, a race condition can't violate memory safety in a Rust program on its own."

> In a sense, Rust is the Ada of a younger generation, and without the baggage.

Not quite. It's kind of discouraging to me how many of the older generation roll their eyes when you mention Ada, or relate stories of how it didn't work out for previous places of employment.

> Of course you sometimes have to use "unsafe" programming evading the borrow checker, just like pointers are sometimes a necessity in Ada...

The only time I've found it necessary (so far) to use the "unsafe" keyword is when interfacing with C or C++. There are people, and probably entire fields of IT, where "unsafe" may be much more common.

> and the legibility becomes truly awful IMHO really fast (to me, this is THE Achilles heel nobody seems to care too much about

I agree with this. It's not as bad as C++, not even as bad as C IMHO, but the braces get old. If not for IDEs that can help navigate them, I'd get lost pretty easily.

> The whole memory safety thing with the borrow checker goes beyond a gimmick, and it has a solid quality which goes beyond "in Ada you don't need pointers most of the time". It's a compile-time check, and it makes evident that runtime checks are a poor substitute.

In addition, the compiler's error messages are *very* useful, better than GNAT's for certain. The only time we have trouble making sense of them is, again, when we have to interface with C or C++ code.

(Well, except when I was learning. I got pretty frustrated with the compiler error messages at times. And I still haven't figured out Rust's manner of organizing modules; if I do understand it, then "lib.rs" is a much bigger deal than I think it should be. But I probably just don't understand well enough yet.)

> I'm more ashamed now of the whole anonymous pointers and accessibility surprises in Ada. Yes, SPARK added something similar for pointers, but in Rust it is for all variables. The equivalence in Ada would be not being able to use the same variable in two consecutive calls as an in-out parameter. So it's not the same, besides being only in SPARK. 

Maybe I misunderstand, but I think the analogy's incorrect. When you designate a Rust variable as mutable, you can in fact have two consecutive calls in a manner akin to "in out", _so long as_ the function declares it wants to "borrow" the variable as mutable, *and* so long as the caller gives permission for both the borrow and the mutability. If it doesn't, the compiler gives a very clear error message.

I'm not sure Ada has anything comparable to that.

> Not having done anything of real import, I'm not sure how inevitable it is to go unsafe in Rust.

At work we have a fairly non-trivial Rust system that, as far as I know, goes unsafe only when... you can fill in the blank. :-)

> And that is what how I would summarize it: Rust is better in a single narrow sense, but Ada is better as a general language.

I haven't played with Ada's task & rendezvous mechanisms in a long time. Do they guarantee an absence of data races? If not, I'd say that's something else Rust has that Ada doesn't. I think SPARK does guarantee that, though. (If I understand correctly, the key is to disallow mutable objects being passed to multiple tasks / threads / etc.)

> Rust is demanding on the programmer in a way that C/C++ aren't...

Perhaps, C/C++ are demanding on the programmer in all kinds of ways that Rust isn't, and none of those ways is good. ;-) Whereas Rust's demands are pretty much all good (in comparison to C/C++).

I would also add that Rust has an amazing and effective ecosystem of libraries that are extremely easy to download and build, all as part of the generally-used Cargo build tool, which as far as I can tell is much easier to use and much more robust than ant, gradle, make, etc. I have the impression that alire is inspired by Cargo, but I haven't used alire at all yet, so I don't know how it compares beyond the ability to create projects and download libraries. I also don't know if alire is nearly as comprehensive as what Cargo offers (see, for instance, https://crates.io/, which offers tens of thousands of crates, and https://docs.rs/, which documents them -- alire has about 220 crates).

I have a feeling that abundance of crates, and the ease of incorporating and using them, has at least as much appeal as the guarantees on any safe code you may write.

john perry

Re: Adacore joins with Ferrous Systems to support Rust

[Marius Amado-Alves]

> > and the legibility becomes truly awful IMHO really fast (to me, this is THE Achilles heel nobody seems to care too much about
> I agree with this. It's not as bad as C++, not even as bad as C IMHO, but the braces get old. If not for IDEs that can help navigate them, I'd get lost pretty easily.
Agree too, but only because they use K&R style. I find Allman style quite readable.

Re: Adacore joins with Ferrous Systems to support Rust

[Alejandro R. Mosteo]

On 12/2/22 6:22, John Perry wrote:
> Here's what Rust promises: https://doc.rust-lang.org/nomicon/races.html
> 
> "Safe Rust guarantees an absence of data races, which are defined as... [omitted] Rust does not prevent general race conditions. This is pretty fundamentally impossible, and probably honestly undesirable. ... So it's perfectly "fine" for a Safe Rust program to get deadlocked or do something nonsensical with incorrect synchronization. ... Still, a race condition can't violate memory safety in a Rust program on its own."

Thanks for the reference, it's essentially what I thought.

> I agree with this. It's not as bad as C++, not even as bad as C IMHO, but the braces get old. If not for IDEs that can help navigate them, I'd get lost pretty easily.

For me, it's not so much the braces as the reference/lifetime &'!<> soup.

>> I'm more ashamed now of the whole anonymous pointers and accessibility surprises in Ada. Yes, SPARK added something similar for pointers, but in Rust it is for all variables. The equivalence in Ada would be not being able to use the same variable in two consecutive calls as an in-out parameter. So it's not the same, besides being only in SPARK.
> 
> Maybe I misunderstand, but I think the analogy's incorrect. When you designate a Rust variable as mutable, you can in fact have two consecutive calls in a manner akin to "in out", _so long as_ the function declares it wants to "borrow" the variable as mutable, *and* so long as the caller gives permission for both the borrow and the mutability. If it doesn't, the compiler gives a very clear error message.

Yes, it is as you say. It is not a perfect analogy, and rethinking a bit 
more about it it's possible I was wrong including non-pointers. In Ada 
there's no trouble by default either; you have to mark things aliased, 
or take an 'Access/'Unchecked_Access to start to get into trouble.

With tasking involved is another matter, there Ada provides no safety 
when using global variables.

> I'm not sure Ada has anything comparable to that.

No, I think that's the novelty in Rust, the single-ownership model.

> At work we have a fairly non-trivial Rust system that, as far as I know, goes unsafe only when... you can fill in the blank. :-)

Hehehe :)

>> And that is what how I would summarize it: Rust is better in a single narrow sense, but Ada is better as a general language.
> 
> I haven't played with Ada's task & rendezvous mechanisms in a long time. Do they guarantee an absence of data races? 

Not for global variables, yes for task-local ones. For any decent design 
you'd encapsulate any shared data in a protected object or task, which 
would give the same assurance as the bit you quoted for Rust. Then 
there's Pragma Detect_Blocking, but that will only work for protected 
operations, and two tasks getting in a mutual deadlock needs not to 
involve protected operations.

> If not, I'd say that's something else Rust has that Ada doesn't. I think SPARK does guarantee that, though. (If I understand correctly, the key is to disallow mutable objects being passed to multiple tasks / threads / etc.)

I agree here. Rust prevents misuse of global variables at the low level 
of simultaneous access (from what you referenced before). This certainly 
can be useful in refactorings going from a single- to a multi-threaded 
design. In Ada you'd have to inspect every package for global state. 
SPARK deals with that, of course, but again: not Ada.

>> Rust is demanding on the programmer in a way that C/C++ aren't...
> 
> Perhaps, C/C++ are demanding on the programmer in all kinds of ways that Rust isn't, and none of those ways is good. ;-) Whereas Rust's demands are pretty much all good (in comparison to C/C++).

Sure, that's a good point: it's not easy but it's for a good cause. 
That's another point I see in common with the Ada compiler. Still, I 
feel Ada is simpler for beginners. You don't need to face the harshness 
of the more complex aspects of the language, perhaps owing to simpler 
imperative roots. In Rust you must face the borrow checker head on.

> I would also add that Rust has an amazing and effective ecosystem of libraries that are extremely easy to download and build, all as part of the generally-used Cargo build tool, 

The ecosystem certainly is a selling point. Look at Python; for quick 
and dirty there's nothing better simply because you know there's going 
to be the library you need.

> I have the impression that alire is inspired by Cargo, but I haven't used alire at all yet, so I don't know how it compares beyond the ability to create projects and download libraries. 

The inspiration is there in a broad sense, but Alire is much younger and 
the manpower behind it is a fraction. For now we strive to cover the 
basics. There's also ideas from opam, virtualenvs, ... In some aspects 
Alire may be even more comprehensive (like crate configuration).

> I also don't know if alire is nearly as comprehensive as what Cargo offers [...] alire has about 220 crates).

No need to guess, given the difference in size of the communities.

> I have a feeling that abundance of crates, and the ease of incorporating and using them, has at least as much appeal as the guarantees on any safe code you may write.

Sure it's appealing. In many (most?) cases, as you say, it can tip the 
scales. Still, I don't think anyone that keeps on using Ada is doing it 
for the amount of ready-to-use libraries. It's a problem to attract new 
people, though. And it may disqualify Ada when a particular dependency 
is important and too costly to bind.

Re: Adacore joins with Ferrous Systems to support Rust

[J-P. Rosen]

Le 12/02/2022 à 19:24, Alejandro R. Mosteo a écrit :
> I agree here. Rust prevents misuse of global variables at the low level 
> of simultaneous access (from what you referenced before). This certainly 
> can be useful in refactorings going from a single- to a multi-threaded 
> design. In Ada you'd have to inspect every package for global state. 
> SPARK deals with that, of course, but again: not Ada.

AdaControl has a rule for that: Global_References

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52
https://www.adalog.fr

Re: Adacore joins with Ferrous Systems to support Rust

[Randy Brukardt]

"Alejandro R. Mosteo" <alejandro@mosteo.com> wrote in message 
news:su8ts8$fej$1@dont-email.me...
> On 12/2/22 6:22, John Perry wrote:
...
>> I haven't played with Ada's task & rendezvous mechanisms in a long time. 
>> Do they guarantee an absence of data races?
>
> Not for global variables, yes for task-local ones. For any decent design 
> you'd encapsulate any shared data in a protected object or task, which 
> would give the same assurance as the bit you quoted for Rust. Then there's 
> Pragma Detect_Blocking, but that will only work for protected operations, 
> and two tasks getting in a mutual deadlock needs not to involve protected 
> operations.

Ada 2022 has "conflict checking" to detect and reject bad uses of global 
variables. It's especially important for the parallel constructs (for which 
you don't have the syntactic guardrails that you get with tasks. It doesn't 
prevent every data race, but it eliminates most of them. (You can still get 
in trouble with accesses to multiple objects; that isn't necessarily safe 
even if accesses to the individual objects are.)

But, so far as I know, GNAT doesn't implement it yet.

                                  Randy.

Re: Adacore joins with Ferrous Systems to support Rust

[Paul Rubin]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> It doesn't prevent every data race, but it eliminates most of
> them. (You can still get in trouble with accesses to multiple objects;
> that isn't necessarily safe even if accesses to the individual objects
> are.)

I wonder if we need software transactional memory:

https://research.microsoft.com/en-us/um/people/simonpj/papers/stm/stm.pdf
https://research.microsoft.com/~simonpj/Papers/stm/beautiful.pdf

In the second paper, jump to the bottom of page 7 to skip a bunch of
introductory stuff.

Re: Adacore joins with Ferrous Systems to support Rust

[John Perry]

First, I agree with Alejandro about the reference/lifetime soup. The other day I saw an expression along the lines of &[&something] and thought, "what"? If I look & think hard enough, I can figure out what that means, but words would be so much nicer, and searching for the meaning of a word is a bit easier than searching for "[]".

On the other hand, again: the tooling and error messages are really very good. "cargo clippy" gives a lot of helpful advice/lint. I think one of the regular correspondents here sells or maintains one for Ada, but I can't remember the name.

Anyway, I want to walk back part of what I said about Rust's safety, related to a post in a reddit thread where someone writes, "having students develop in Ada lead to them jumping from exception to exception until it worked, while other students writing code for the same problem in Rust lead to them swearing for 4 days until their code compiled and then being surprised that their code works, 100% as they expected and not ever producing a runtime error until the end of the two week practicum."

   https://www.reddit.com/r/ada/comments/7wzrqi/why_rust_was_the_best_thing_that_could_have/

Maybe, but long term I'm not so sure.

Rust doesn't have a null in safe mode, so the idiomatic way to indicate an error is via a Result enum, which has two variants: Ok(result), where "result" is the desired result, or Err(msg), where "msg" is an error message.

   https://doc.rust-lang.org/std/result/enum.Result.html

The "smart" way to handle a Result is to "match" it, basically an Ada case statement. (I confess that I prefer this to the approach in Ada's standard library, where, for instance, if I try to look up a non-existent key in a HashMap, it errors out with an exception.)

In any case, handling the Result can be a little tedious (only a little but still!) so people often use the standard library's ".unwrap()" function instead. That means something akin to, "I'm confident the preceding expression had an Ok result, so just hand me the result. If it's an Err then go ahead and panic with Err's msg."

Not all Rust users think much about that "panic" part. Err's msg can be pretty bare-bones, and as the Rust Book itself states, using .unwrap() a lot can make errors hard to track down:

   https://doc.rust-lang.org/book/ch09-02-recoverable-errors-with-result.html#shortcuts-for-panic-on-error-unwrap-and-expect

Technically this doesn't violate Rust's guarantees, but it's better to use .expect(msg), where you add a (hopefully) useful msg which gets reported along with the panic message.

But a lot of Rust users default to .unwrap() all the same, which makes me think that issue about Ada users jumping from exception to exception may be a feature of a lot of Rust code, too. Depends on the self-discipline, I guess.

Re: Adacore joins with Ferrous Systems to support Rust

[Kevin Chadwick]

> If possible please tell what Rust has to offer over Ada. 
> From a quick look at the Rust book it seemed weaker in structured programming, generic programming, type system. 
> Thanks.

I haven't written a single line of Rust and do not intend to but I have done some research 
before and after choosing Ada, to confirm my choice due to Rusts popularity. My biggest 
preference is Ada's readability, of course some love brevity even when it adds complexity 
for some reason that I cannot understand.

Adas type system has already been mentioned, but is fantastic.

Another is that Ada has a focus on Stack and has tried to offer more heap tools in recent decades. 
Rust has a focus on heap. I prefer the simpler stack default! Personally I avoided the heap, even with
C.

I have heard that Rusts ownership model can cause problem with local/stack usage of owned 
memory (podcast interviewing a core maintainer "Rust with Steve Klabnik" but from 2015).

I have seen Rusts unsafe used even for simple things in embedded Rust whilst removing ALL
of their 3 protections. Whereas with Ada you can more precisely permit pointer use and rarely 
need to. 

"https://docs.rs/svd2rust/0.19.0/svd2rust/#peripheral-api"

struct PA0 { _0: () }
impl PA0 {
    fn is_high(&self) -> bool {
        // NOTE(unsafe) actually safe because this is an atomic read with no side effects
        unsafe { (*GPIOA::ptr()).idr.read().bits() & 1 != 0 }
    }

    fn is_low(&self) -> bool {
        !self.is_high()
    }
}

Ada has been engineered to avoid pointer use, which I find appealing. Rust users would cite 
memory flexibility as appealing.

"Why Pascal is Not My Favorite Programming Language" by Kernighan is sometimes brought up, 
though much of it does not apply to Ada and no longer applies in any case and is clearly biased.
Does he really promote the use of #include! 
Personally I blame flexibility points of view like his as the primary cause, as to why I have critical
updates on my phone every single month and spend many days per year vulnerable to known 
exploits. Though really it is management at Vendors relentlessly pushing C. Maybe Rust can shift 
that closed point of view? I am aware that if my business does not succeed then the opportunity
to write Ada, may go with it.

WRT compile time checks vs runtime. 
GO was written precisely because it's authors were fed up waiting for C++ to compile. For me 
it is not important but worth bearing in mind.
Personally I like the simplicity of runtime checks. I have much more faith in them than compile 
time checks!
Though I confess to not knowing the details well enough to make that statement with complete 
confidence. It would also be nice to handle them more easily in a ZFP runtime.

SPARK sounds great and I like how it is intended to be applied where needed but I am dubious 
of any text that says it proves this or that, when it often depends on the tests implemented. 
I much prefer the language used by one AdaCore member in a podcast (Paul Butcher) along 
the lines of providing a high degree of confidence/assurance.

Re: Adacore joins with Ferrous Systems to support Rust

[Paul Rubin]

"Luke A. Guest" <laguest@archeia.com> writes:
> I see this going one way, Ada loses out as the Rust side uses AdaCore
> to get what they want.

I don't think this is two companies merging.  It's two companies working
jointly on a particular product.  Idk any more than the press release
though.

Regarding Rust vs Ada, I've never heard anything from anyone who is a
real expert at both.  Superficially it looks to me like Rust's type
system really is more precise than Ada's in general, although it doesn't
have integer range types.  In other stuff like modules, Ada is probably
still ahead.

Re: Adacore joins with Ferrous Systems to support Rust

[Luke A. Guest]

On 02/02/2022 20:06, Paul Rubin wrote:
 > "Luke A. Guest" <laguest@archeia.com> writes:
 >> I see this going one way, Ada loses out as the Rust side uses AdaCore
 >> to get what they want.
 >
 > I don't think this is two companies merging.  It's two companies working
 > jointly on a particular product.  Idk any more than the press release

I know. I never said otherwise. I just said I think that one will use 
the other and not in Ada's favour.

 > though.
 >
 > Regarding Rust vs Ada, I've never heard anything from anyone who is a
 > real expert at both.  Superficially it looks to me like Rust's type

I've heard nothing either, only keep seeing rust people demanding to 
know what Ada's good for and how it compares to Rust. Er, try learning 
both and you'll see?

 > system really is more precise than Ada's in general, although it doesn't

How is it?

 > have integer range types.  In other stuff like modules, Ada is probably

Apparently, they have ranges as templates, can't see how that compensates.

 > still ahead.

Ada's ahead in most things.

Re: Adacore joins with Ferrous Systems to support Rust

[Paul Rubin]

"Luke A. Guest" <laguest@archeia.com> writes:
> [Ada vs Rust] Er, try learning both and you'll see?

It's a big effort to become expert at either, let alone both.  Basic or
superficial knowledge isn't helpful for such comparisons.  I've read
"Ada Distilled" (Ada 95 version) but still have no clue understanding
most of the Ada discussions in this newsgroup, so there is a big gap
between basic and advanced knowledge of Ada.

>> system really is more precise than Ada's in general, although it doesn't
> How is it?

From what I've heard, Rust's type system is similar to Haskell's.
Haskell's type system can verify stuff just by typechecking, that might
be doable in Ada using SPARK and maybe an external proof assistant, but
not with just types.  Example: a red-black tree using Haskell GADT's
(Generalized Algebraic Data Types):

https://www.reddit.com/r/haskell/comments/ti5il/redblack_trees_in_haskell_using_gadts_existential/

> Ada's ahead in most things.

Idk, I'd like to know more.  I've never done anything serious in Ada and
nothing at all in Rust, but C++ seems a lot more fluid than Ada, and
Rust is supposed to compare well with C++.  C++ of course is terrible in
terms of reliability but I'm only referring to the effort needed to bang
out a chunk of code.

Re: Adacore joins with Ferrous Systems to support Rust

[Luke A. Guest]

On 03/02/2022 02:20, Paul Rubin wrote:
> "Luke A. Guest" <laguest@archeia.com> writes:
>> [Ada vs Rust] Er, try learning both and you'll see?
> 
> It's a big effort to become expert at either, let alone both.  Basic or
> superficial knowledge isn't helpful for such comparisons.  I've read

You don't need to learn both languages inside and out. You pick a 
project and implement it in both languages, that project has to be 
specific to what you are wanting to know about whether it's binding or 
tasking or whatever, Ultimately with Ada, you can get by knowing the Ada 
subset and the representation clauses and do most of what you need to do 
to compare to another language, obviously if you want to compare 
tasking, you need to go further.

> "Ada Distilled" (Ada 95 version) but still have no clue understanding
> most of the Ada discussions in this newsgroup, so there is a big gap
> between basic and advanced knowledge of Ada.

Learn the basic part, it's equivalent to Pascal with proper type ranges, 
Pascal only has subtypes iirc. That's the main part of the RM, no 
annexes, you can do without access and tagged/controlled types to start 
with. At uni, we didn't even touch on tagged types, but used controlled 
types, it is possible.

>>> system really is more precise than Ada's in general, although it doesn't
>> How is it?
> 
>  From what I've heard, Rust's type system is similar to Haskell's.
> Haskell's type system can verify stuff just by typechecking, that might

So it's no different than a C++ compiler checking against classes or a 
variant of C with strong typing? Still no ranges, subranges, ranges with 
holes in, etc. This is where the power is.

> be doable in Ada using SPARK and maybe an external proof assistant, but
> not with just types.  Example: a red-black tree using Haskell GADT's
> (Generalized Algebraic Data Types):
> 
> https://www.reddit.com/r/haskell/comments/ti5il/redblack_trees_in_haskell_using_gadts_existential/

I don't know Haskell. Uni did a shit job at teaching functional, and 
logic languages.

>> Ada's ahead in most things.
> 
> Idk, I'd like to know more.  I've never done anything serious in Ada and
> nothing at all in Rust, but C++ seems a lot more fluid than Ada, and
> Rust is supposed to compare well with C++.  C++ of course is terrible in
> terms of reliability but I'm only referring to the effort needed to bang
> out a chunk of code.

1. What do you want to do?
2. Come into #Ada and get help.
3. Rewrite it in Rust.
4. Ada is comparable to C++.
   4a. Ada > C++ in many ways.

Re: Adacore joins with Ferrous Systems to support Rust

[Paul Rubin]

"Luke A. Guest" <laguest@archeia.com> writes:
> You don't need to learn both languages inside and out. You pick a
> project and implement it in both languages,

Not realistic, as the saying is that it's possible to write Fortran in
any language.  What I want to see is proper idiomatic usage of both
languages as experts would write them.  Also, it seems to me that one of
Ada's big strengths is its modularity, e.g. the separation of
specification from implementation.  And that makes itself felt more with
large programs than small ones.  A beginner or tryout project wouldn't
exercise this.

> [Ada] Learn the basic part,

I think I have done that, but there is a heck of a lot more.

> [Haskell] So it's no different than a C++ compiler checking against
> classes or a variant of C with strong typing?

It is very different from either of those.

> Still no ranges, subranges, ranges with holes in, etc. This is where
> the power is.

No not really, especially since Ada doesn't enforce ranges with (static)
type checking, although it is sometimes possible in SPARK.  Range types
are a nice Ada feature but only "where the power is" if you haven't used
anything else ;).  Anyway, you can implement ranges (with runtime
checks) in C++ or Haskell with a bit of pain.

>> Example: a red-black tree using Haskell GADT's
> I don't know Haskell. Uni did a shit job at teaching functional, and
> logic languages.

Well are you familiar with red-black trees?  They are a data structure
similar to B-trees which you may have seen.  Basically the trees have
nodes that are coloured either red or black, and there are some rules
such as that internal red nodes can have only black children, and that
enforces some invariants that keep the trees balanced so that lookups
and updates are guaranteed to run fairly fast.

Now these trees have been implemented in many languages, and if you look
at almost any implementation, there is usually a test suite or internal
debugging code to make sure that the invariants are preserved after
doing an update.  It is quite easy to make a mistake after all.  But the
Haskell code doesn't have those tests.  Why not?  Because the invariants
are enforced by the datatype!  If you make a mistake and mess up an
invariant, your code won't compile!  It's the difference between
checking a subscript at runtime, and verifying that it in range with
SPARK.  SPARK lets you get rid of the runtime check.  Haskell's type
system is able to do similar things.

> 1. What do you want to do?

I have too many obligations and wannado projects to embark on anything
well suited for either Ada or Rust right now, unless someone is paying
me.  Also, I see Ada and Rust not really aiming at the same areas.  I
think of Ada as being more for control programs (they might compute a
lot, but tend not to make complex use of dynamic memory allocation)
while Rust is the opposite (handling dynamic allocation reliably is a
big part of the design motivation).

> 4. Ada is comparable to C++.
>   4a. Ada > C++ in many ways.

I don't see Ada and C++ as really comparable.  Ada > C++ in reliability
for sure, but C++ > Ada in convenience a lot of the time.

Particularly, a lot of effort in Ada programming goes into making
programs never crash.  For example, if the program runs out of memory
during operation it might crash, so Ada programs are often written to
never allocate new memory after a startup phase.  In C++ or Rust, it's
important not to get wrong answers like 2+2=5, but if your program runs
out of memory and crashes, go get a bigger computer.  So idiomatic C++
and Rust programming uses dynamic allocation freely, and that makes some
kinds of programming more convenient, at the expense of tolerating
possible crashes.

Re: Adacore joins with Ferrous Systems to support Rust

[Björn Lundin]

Den 2022-02-03 kl. 05:22, skrev Paul Rubin:

> Particularly, a lot of effort in Ada programming goes into making
> programs never crash.  For example, if the program runs out of memory
> during operation it might crash, so Ada programs are often written to
> never allocate new memory after a startup phase.  In C++ or Rust, it's
> important not to get wrong answers like 2+2=5, but if your program runs
> out of memory and crashes, go get a bigger computer.  So idiomatic C++
> and Rust programming uses dynamic allocation freely, and that makes some
> kinds of programming more convenient, at the expense of tolerating
> possible crashes.


That depends on the domain. Perhaps it is true in embedded.
I use Ada for large systems, talking to databases,
and lots of administrative work. On a win/Unix server.
We would not dream of pre-allocate memory at startup.
We allocate and dispose as needed.

-- 
Björn

Re: Adacore joins with Ferrous Systems to support Rust

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87v8xwy3y7.fsf@nightsong.com...
...
> Well are you familiar with red-black trees?  They are a data structure
> similar to B-trees which you may have seen.  Basically the trees have
> nodes that are coloured either red or black, and there are some rules
> such as that internal red nodes can have only black children, and that
> enforces some invariants that keep the trees balanced so that lookups
> and updates are guaranteed to run fairly fast.
>
> Now these trees have been implemented in many languages, and if you look
> at almost any implementation, there is usually a test suite or internal
> debugging code to make sure that the invariants are preserved after
> doing an update.  It is quite easy to make a mistake after all.  But the
> Haskell code doesn't have those tests.  Why not?  Because the invariants
> are enforced by the datatype!  If you make a mistake and mess up an
> invariant, your code won't compile!  It's the difference between
> checking a subscript at runtime, and verifying that it in range with
> SPARK.  SPARK lets you get rid of the runtime check.  Haskell's type
> system is able to do similar things.

Cool, and most likely useless. OOP is like that in many ways, it lets you 
make a bunch of static checks, but to get them, you have to contort your 
design in awful ways. And then it is hard to extend, as you have a huge 
number of routines to override to get anything done.

I'm convinced that the answer (as much as there is an answer -- always 
beware of anyone bearing silver bullets ;-) is in the quality of tools (and 
language implementations). In any language with dynamic checks, one can 
easily reduce the problem of correctness down to simply proving that no 
check fails. So the question is how one can accomplish that with the least 
complication for the actual programmer.

Janus/Ada has a switch that can give you a warning for any implicit check 
that remains in the code after optimization. Combine that with the 
warnings-as-errors switch, and no program that could have a (detectable) bug 
can compile. Moreover, in Ada at least, one can introduce essentially any 
condition that you want to know as some form of assertion.

To take your red-black example. In Ada, I'd model the tree as a single type 
with two subtypes, with Red and Black predicates that enforce the 
conditions. Then, using the switches mentioned above, you could only compile 
the program if the compiler can eliminate the condition checks (it should be 
able to, if they are really complete).

The problem with this scheme, of course, is the quality of the 
implementation in terms of eliminating unneeded checks. For now, Janus/Ada 
can only do this sort of elimination inside of an extended basic block, and 
if something prevents a subprogram from being converted to a single extended 
basic block, you're likely to get spurious warnings. (And it only implements 
advanced elimination on a few kinds of checks, enough to prove the concept 
but not enough to be practical.)

The key for a programming language design is to minimize what Ada calls 
erroneous execution (undefined behavior), because it is that possibility 
which stop proofs in their tracks (or at least should; at least some tools 
ignore that possibility and essentially give garbage results as a 
consequence). Ada needs work in that area, but most other languages need 
more -- Ada at least detects most problems with dynamic checks.

Anyway, that's my 20 cents (inflation, you know). :-)

                             Randy.

Re: Adacore joins with Ferrous Systems to support Rust

[Paul Rubin]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> In any language with dynamic checks, one can easily reduce the problem
> of correctness down to simply proving that no check fails.

Well sure, but I'd take issue with the word "easily" there.  The
invariants for the red-black tree are fairly complicated.  Enforcing
them could be done with what I think SPARK calls a "ghost function" or
something like that: a piece of code that is not actually executed, but
is used only by the prover.  But, what would the proof look like?  I
think it would likely involve some manual work with an external proof
assistant like ISABELLE.  That takes quite a bit of effort and knowledge
on the programmer's part.

On the other hand, the RB tree type declaration in that Haskell example
is very natural and appealing even in that old implementation, and using
newer GHC features that have appeared since then, it becomes even nicer.

> So the question is how one can accomplish that with the least
> complication for the actual programmer.

Indeed.

Re: Adacore joins with Ferrous Systems to support Rust

[Simon Wright]

"Luke A. Guest" <laguest@archeia.com> writes:

> At uni, we didn't even touch on tagged types, but used controlled
> types

Of course controlled types are implemented as tagged types. ISTR Dmitry
objecting to this, I think he was right (philosophically; I've no idea
about the practicality of alternate approaches).

Re: Adacore joins with Ferrous Systems to support Rust

[Luke A. Guest]

On 03/02/2022 11:30, Simon Wright wrote:
> "Luke A. Guest" <laguest@archeia.com> writes:
> 
>> At uni, we didn't even touch on tagged types, but used controlled
>> types
> 
> Of course controlled types are implemented as tagged types. ISTR Dmitry

We had a book with a reading guide. We weren't shown the specs showing 
the type of controlled/limited_controlled. So, when you don't have that 
information and only know that you can derive from it and then implement 
2 or 3 subprograms, you don't need to know about OOP in Ada.

Just like we didn't touch generic packages until much later in the year, 
generic subprograms, yeah, because u_d was required early on.

> objecting to this, I think he was right (philosophically; I've no idea
> about the practicality of alternate approaches).

How else would you do controlled types?

Re: Adacore joins with Ferrous Systems to support Rust

[Randy Brukardt]

"Luke A. Guest" <laguest@archeia.com> wrote in message 
news:stgj3j$12g8$1@gioia.aioe.org...
> On 03/02/2022 11:30, Simon Wright wrote:
>> "Luke A. Guest" <laguest@archeia.com> writes:
>>
>>> At uni, we didn't even touch on tagged types, but used controlled
>>> types
>>
>> Of course controlled types are implemented as tagged types. ISTR Dmitry
>
> We had a book with a reading guide. We weren't shown the specs showing the 
> type of controlled/limited_controlled. So, when you don't have that 
> information and only know that you can derive from it and then implement 2 
> or 3 subprograms, you don't need to know about OOP in Ada.
>
> Just like we didn't touch generic packages until much later in the year, 
> generic subprograms, yeah, because u_d was required early on.
>
>> objecting to this, I think he was right (philosophically; I've no idea
>> about the practicality of alternate approaches).
>
> How else would you do controlled types?

Ada 9x originally had a bunch of magic attributes (similar to streaming). It 
was very complex and got dumped in the dustbin during "scope reduction". 
Later on, some of us were bemoaning that a critical feature (finalization) 
had gotten lost in Ada 9x, and Tucker came up with the idea to build it on 
top of tagged types as a massive simplification (at the loss of a bit of 
power). People often complain that Ada finalization is complex, and it is, 
except all of the alternatives are a lot more complex. :-)

                   Randy.

Re: Adacore joins with Ferrous Systems to support Rust

[Luke A. Guest]

On 04/02/2022 03:20, Randy Brukardt wrote:

>> Just like we didn't touch generic packages until much later in the year,
>> generic subprograms, yeah, because u_d was required early on.
>>
>>> objecting to this, I think he was right (philosophically; I've no idea
>>> about the practicality of alternate approaches).
>>
>> How else would you do controlled types?
> 
> Ada 9x originally had a bunch of magic attributes (similar to streaming). It

Now I want to know what these magic attributes were! Were they specific 
to a version of OO? Or were they to enable finalization?

Re: Adacore joins with Ferrous Systems to support Rust

[Andreas ZEURCHER]

On Friday, February 4, 2022 at 4:28:26 AM UTC-6, Luke A. Guest wrote:
> On 04/02/2022 03:20, Randy Brukardt wrote: 
> 
> >> Just like we didn't touch generic packages until much later in the year, 
> >> generic subprograms, yeah, because u_d was required early on. 
> >> 
> >>> objecting to this, I think he was right (philosophically; I've no idea 
> >>> about the practicality of alternate approaches). 
> >> 
> >> How else would you do controlled types? 
> > 
> > Ada 9x originally had a bunch of magic attributes (similar to streaming). It
> Now I want to know what these magic attributes were! Were they specific 
> to a version of OO? Or were they to enable finalization?

Randy, I agree with Luke:  were these intermediate design proposals lost entirely or have they (as still extant) have simply not been released publicly?  I suspect that at least some of these attributes have nowadays analogues in C++ smart pointer's & Objective-C/Swift's ARC {strong, weak, plain old data not needing finalization, pointed-to-object ownership, presence of finalization subroutine/function/procedure a.k.a. finalizer/destructor, whether this finalizer in a subtype displaces its parent's finalizer versus this finalizer in a subtype chains its finalizer to all of its ancestors' finalizers unwound from most-derived to underived-root, … and so forth}.  Or was Tucker's set of magic attributes going an entirely different direction?  That intermediate proposal under consideration back in the 1st half of the 1990s might be a quite interesting read (especially by a reader with an interest in envisioning an Ada-esque analogue of Rust's borrow-checker algorithm).

Re: Adacore joins with Ferrous Systems to support Rust

[Randy Brukardt]

"Luke A. Guest" <laguest@archeia.com> wrote in message 
news:stiv47$bvh$1@gioia.aioe.org...
> On 04/02/2022 03:20, Randy Brukardt wrote:
>
>>> Just like we didn't touch generic packages until much later in the year,
>>> generic subprograms, yeah, because u_d was required early on.
>>>
>>>> objecting to this, I think he was right (philosophically; I've no idea
>>>> about the practicality of alternate approaches).
>>>
>>> How else would you do controlled types?
>>
>> Ada 9x originally had a bunch of magic attributes (similar to streaming). 
>> It
>
> Now I want to know what these magic attributes were! Were they specific to 
> a version of OO? Or were they to enable finalization?

They were specifically for finalization, and got called automatically in 
various places.

Re: Andreas. So far as I know, the documents existed only on paper - there 
never were any electronically distributed versions outside of the Ada 9x 
team (and possibly the printers). I still have a set of them on my 
bookshelf -- I look at them periodically to see where current oddities 
appeared in the language (and possibly to get some idea why). [But see 
below.]

Looking in the RM 3.0 (the final version was 6.0 for reference), it already 
had the tagged type version, but they were derived from an implementation 
defined type "Finalization_Implementation", and what became Adjust was named 
Duplicate.

Looking in ILS 1.2 (a working document full of ideas but not quite a 
complete RM, dated Dec 1992), I can't find any sign of finalization. It must 
have been gone by then.

I do have a large number of older documents somewhere in storage, but this 
isn't worth digging around in there to find out. Most of those were 
incomplete design documents.

You might be able to find something about that design in the Ada 9x mail 
archive or in the LSNs (Language Study Notes). You can find them on the 
AdaIC archives. =Rooting around in there, there are some promising looking 
documents in the "history" section of the AdaIC archives. There is a 
directory of stuff called "9x-history"; there probably is interesting stuff 
there.
    http://archive.adaic.com/pol-hist/history/9x-history/
LSNs are found in:
    http://archive.adaic.com/standards/95lsn/
The Ada 9x mail archive (These were known as "MRT comments"):
    http://archive.adaic.com/standards/95com/mrtcomments/
The comments of interest here are probably in the ZIPed comments rather than 
the more recent ones. (These are text files, I think, even though they don't 
have a usual extension.)

                                    Randy.

Re: Adacore joins with Ferrous Systems to support Rust

[Stephen Leake]

Paul Rubin <no.email@nospam.invalid> writes:

> https://blog.adacore.com/adacore-and-ferrous-systems-joining-forces-to-support-rust
>
> Ferrous Systems is apparently a Rust support company based in Germany.
> From the linked page:
>
>     "Ferrous Systems and AdaCore are announcing today that they’re
>     joining forces to develop Ferrocene - a safety-qualified Rust
>     toolchain, which is aimed at supporting the needs of various
>     regulated markets, such as automotive, avionics, space, and
>     railway."
>
> No mention about whether there will be any type of FOSS or community
> release.  No word on whether the compiler and/or toolchain will be based
> on the existing stuff, or something new.  Wonder how they will
> safety-certify anything in Rust when the language itself doesn't even
> have a formal spec.  But, it is an interesting development.
>
> Is the writing on the wall for Ada?

Yes. And it says:

   As long as people care about quality software engineering, they will
   use Ada.

:)

-- 
-- Stephe

Re: Adacore joins with Ferrous Systems to support Rust

[Gautier write-only address]

> Is the writing on the wall for Ada?

Don't worry too much, people said that already more than 30 years ago...
But perhaps the company will rebrand itself RustCore :-) ?

Re: Adacore joins with Ferrous Systems to support Rust

[Paul Rubin]

Gautier write-only address <gautier_niouzes@hotmail.com> writes:
> But perhaps the company will rebrand itself RustCore :-) ?

If the new IDE is called Oxide, watch out ;-).

Re: Adacore joins with Ferrous Systems to support Rust

[Dennis Lee Bieber]

On Wed, 02 Feb 2022 12:03:03 -0800, Paul Rubin <no.email@nospam.invalid>
declaimed the following:

>Gautier write-only address <gautier_niouzes@hotmail.com> writes:
>> But perhaps the company will rebrand itself RustCore :-) ?
>
>If the new IDE is called Oxide, watch out ;-).

	Hemoglobin -- for Red-Blooded Programmers!

{Interesting... per Wikipedia, iron oxide is also a food coloring: E172}


-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

Re: Adacore joins with Ferrous Systems to support Rust

[25.BZ943]

If I wanted to program in Rust I wouldn't be looking
at an Ada group .........

Rust is just 'c' with more annoying syntactic
weirdness. Requiring "LET" to assign something
to a variable ... didn't that go out WAY WAY
back ???

I'll just use 'c' for 'c'-like tasks, thank you.