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.

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.

> 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

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

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.

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.

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.

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

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

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

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

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.