comp.lang.ada
 help / color / mirror / Atom feed
From: John Perry <devotus@yahoo.com>
Subject: Re: Adacore joins with Ferrous Systems to support Rust
Date: Fri, 11 Feb 2022 21:22:50 -0800 (PST)	[thread overview]
Message-ID: <c1a2b567-8dbe-4a9a-ae0d-800759a594cbn@googlegroups.com> (raw)
In-Reply-To: <70f72b7e-1f3f-4942-b6aa-1044430bdcd9n@googlegroups.com>

> 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

  parent reply	other threads:[~2022-02-12  5:22 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-02  8:57 Adacore joins with Ferrous Systems to support Rust Paul Rubin
2022-02-02 13:04 ` Luke A. Guest
2022-02-02 15:29   ` Marius Amado-Alves
2022-02-02 16:36     ` Luke A. Guest
2022-02-04 17:51       ` Stephen Leake
2022-04-18 16:01       ` Rene
2022-02-02 20:07     ` G.B.
2022-02-03 23:29     ` John McCabe
2022-02-11 17:40     ` amo...@unizar.es
2022-02-11 19:24       ` Luke A. Guest
2022-02-12 17:34         ` Alejandro R. Mosteo
2022-02-12  5:22       ` John Perry [this message]
2022-02-12 10:08         ` Marius Amado-Alves
2022-02-12 18:24         ` Alejandro R. Mosteo
2022-02-13  8:10           ` J-P. Rosen
2022-02-14 23:25           ` Randy Brukardt
2022-02-15  4:29             ` Paul Rubin
2022-02-12 23:59         ` John Perry
2022-02-18 13:24     ` Kevin Chadwick
2022-02-02 20:06   ` Paul Rubin
2022-02-03  1:34     ` Luke A. Guest
2022-02-03  2:20       ` Paul Rubin
2022-02-03  2:52         ` Luke A. Guest
2022-02-03  4:22           ` Paul Rubin
2022-02-03  9:54             ` Björn Lundin
2022-02-04  3:38             ` Randy Brukardt
2022-02-04  5:19               ` Paul Rubin
2022-02-03 11:30           ` Simon Wright
2022-02-03 12:51             ` Luke A. Guest
2022-02-04  3:20               ` Randy Brukardt
2022-02-04 10:28                 ` Luke A. Guest
2022-02-04 17:51                   ` Andreas ZEURCHER
2022-02-05  4:31                   ` Randy Brukardt
2022-02-02 16:19 ` Stephen Leake
2022-02-02 18:48 ` Gautier write-only address
2022-02-02 20:03   ` Paul Rubin
2022-02-02 20:45     ` Dennis Lee Bieber
2022-02-12  4:42 ` 25.BZ943
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox