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.8 required=3.0 tests=BAYES_50,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.6 X-Received: by 2002:a05:600c:3546:b0:37d:1bcf:de2c with SMTP id i6-20020a05600c354600b0037d1bcfde2cmr7418061wmq.96.1645190656021; Fri, 18 Feb 2022 05:24:16 -0800 (PST) X-Received: by 2002:a81:154:0:b0:2d0:fc6a:1d37 with SMTP id 81-20020a810154000000b002d0fc6a1d37mr7421160ywb.518.1645190655476; Fri, 18 Feb 2022 05:24:15 -0800 (PST) Path: eternal-september.org!reader02.eternal-september.org!news.mixmin.net!proxad.net!feeder1-2.proxad.net!209.85.128.88.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 18 Feb 2022 05:24:15 -0800 (PST) In-Reply-To: <87d2e0c1-c851-43e2-a085-fad30e475e35n@googlegroups.com> Injection-Info: google-groups.googlegroups.com; posting-host=84.92.86.82; posting-account=5K6RMgoAAADQeoHIOMi2dg5aYc0IVxGi NNTP-Posting-Host: 84.92.86.82 References: <87o83pzlvm.fsf@nightsong.com> <87d2e0c1-c851-43e2-a085-fad30e475e35n@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <7cbebf58-7151-4e00-92bf-c3f2d751a22dn@googlegroups.com> Subject: Re: Adacore joins with Ferrous Systems to support Rust From: Kevin Chadwick Injection-Date: Fri, 18 Feb 2022 13:24:16 +0000 Content-Type: text/plain; charset="UTF-8" Xref: reader02.eternal-september.org comp.lang.ada:63540 List-Id: > 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.