From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=0.0 required=3.0 tests=BAYES_40,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.6 X-Received: by 2002:a0c:f84b:: with SMTP id g11mr3381589qvo.88.1644643371377; Fri, 11 Feb 2022 21:22:51 -0800 (PST) X-Received: by 2002:a0d:fd01:: with SMTP id n1mr5228201ywf.242.1644643371163; Fri, 11 Feb 2022 21:22:51 -0800 (PST) Path: eternal-september.org!reader02.eternal-september.org!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 11 Feb 2022 21:22:50 -0800 (PST) In-Reply-To: <70f72b7e-1f3f-4942-b6aa-1044430bdcd9n@googlegroups.com> Injection-Info: google-groups.googlegroups.com; posting-host=2601:3c3:400:b30:5bbb:11d1:c956:9424; posting-account=JSxOkAoAAADa00TJoz2WZ_46XrZCdXeS NNTP-Posting-Host: 2601:3c3:400:b30:5bbb:11d1:c956:9424 References: <87o83pzlvm.fsf@nightsong.com> <87d2e0c1-c851-43e2-a085-fad30e475e35n@googlegroups.com> <70f72b7e-1f3f-4942-b6aa-1044430bdcd9n@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Adacore joins with Ferrous Systems to support Rust From: John Perry Injection-Date: Sat, 12 Feb 2022 05:22:51 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:63493 List-Id: > I really miss not having the time to become proficient in Rust at least t= o 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 officia= l tutorial a couple of times, what Rust has to offer in general:=20 >=20 > + Memory safety (no leaks, double-free, race conditions*) by default.=20 > ... > [*] I guess in a protected-object sense, not in a high-level logic sense.= But I don't really know.=20 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... [om= itted] Rust does not prevent general race conditions. This is pretty fundam= entally impossible, and probably honestly undesirable. ... So it's perfectl= y "fine" for a Safe Rust program to get deadlocked or do something nonsensi= cal with incorrect synchronization. ... Still, a race condition can't viola= te memory safety in a Rust program on its own." > In a sense, Rust is the Ada of a younger generation, and without the bagg= age. 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 w= ork out for previous places of employment. > Of course you sometimes have to use "unsafe" programming evading the borr= ow 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 fi= elds of IT, where "unsafe" may be much more common. > and the legibility becomes truly awful IMHO really fast (to me, this is T= HE 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 t= he braces get old. If not for IDEs that can help navigate them, I'd get los= t pretty easily. > The whole memory safety thing with the borrow checker goes beyond a gimmi= ck, and it has a solid quality which goes beyond "in Ada you don't need poi= nters most of the time". It's a compile-time check, and it makes evident th= at runtime checks are a poor substitute. In addition, the compiler's error messages are *very* useful, better than G= NAT's for certain. The only time we have trouble making sense of them is, a= gain, when we have to interface with C or C++ code. (Well, except when I was learning. I got pretty frustrated with the compile= r 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 e= nough yet.) > I'm more ashamed now of the whole anonymous pointers and accessibility su= rprises in Ada. Yes, SPARK added something similar for pointers, but in Rus= t it is for all variables. The equivalence in Ada would be not being able t= o use the same variable in two consecutive calls as an in-out parameter. So= it's not the same, besides being only in SPARK.=20 Maybe I misunderstand, but I think the analogy's incorrect. When you design= ate 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 t= o "borrow" the variable as mutable, *and* so long as the caller gives permi= ssion for both the borrow and the mutability. If it doesn't, the compiler g= ives 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 i= s to go unsafe in Rust. At work we have a fairly non-trivial Rust system that, as far as I know, go= es unsafe only when... you can fill in the blank. :-) > And that is what how I would summarize it: Rust is better in a single nar= row 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 pa= ssed 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 Ru= st isn't, and none of those ways is good. ;-) Whereas Rust's demands are pr= etty much all good (in comparison to C/C++). I would also add that Rust has an amazing and effective ecosystem of librar= ies that are extremely easy to download and build, all as part of the gener= ally-used Cargo build tool, which as far as I can tell is much easier to us= e and much more robust than ant, gradle, make, etc. I have the impression t= hat alire is inspired by Cargo, but I haven't used alire at all yet, so I d= on't know how it compares beyond the ability to create projects and downloa= d 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 t= housands 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 an= d using them, has at least as much appeal as the guarantees on any safe cod= e you may write. john perry