Re: Adacore joins with Ferrous Systems to support Rust

["Alejandro R. Mosteo" <alejandro@mosteo.com>]

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.