From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: Intervention needed? Date: Wed, 13 Mar 2019 15:56:10 +0000 Organization: A noiseless patient Spider Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="083e63d4b88bb5d739347a0eccb32b16"; logging-data="3407"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18ZKEIK8FLzzhdCry97E+mSni0uHV0ZKBA=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (darwin) Cancel-Lock: sha1:S+qNcJ3WZePbR9Ejzrhx8V/GtBg= sha1:0GWQ+p4iQXxmDTHyoPa54JTcxGc= Xref: reader01.eternal-september.org comp.lang.ada:55864 Date: 2019-03-13T15:56:10+00:00 List-Id: Olivier Henley writes: > From that excerpt by Oliver Scherer (Rust compiler contributor), it > looks like the ownership aspect that comes with them is a real > improvement: Which excerpt? or, if it's this one, where's it from? > "The two (obviously not a good amount of datapoints) large scale > refactorings in Ada software that I've been part of have resulted in > horrible hacks where people just spammed protected and pragma > everywhere to get stuff working and bug free. The protected injections > are because it's nearly impossible to figure out which things are > accessed by multiple tasks without SPARK and you end up with undefined > behaviour if you accidentally have a shared access to an unprotected > memory location. The pragmas were reconfiguring things like stack size > or disabling compiler warnings without actually thinking about what > these changes meant. Getting the stack size right seems to be a reasonable thing to be worried about. Randomly suppressing compiler warnings without investigating them & fixing or getting sign-off is .. well. As to the tasking & access to unprotected data, you have to agree if the data is got at via accessors. Ada allows large objects to be passed via reference even if the mode is in, so there is an access, just under the hood. I'm sure the clever SPARK guys have thought of this! and they have the Global aspect(s) too. > Refactorings in Rust on the other hand are (compile-time) guaranteed > to be free of race conditions, no matter how crazy you move stuff > around or create new parallelism. Additionally the ownership concept > lead to many libraries typestate encoding their API which makes > misusing them a near impossibility (at compile-time) while Ada mainly > catches those misuses at runtime via exceptions." If you have as undisciplined a refactoring of a tasking application as hinted at in the first para above, you're heading for trouble regardless of the language (IMO, of course). But not having even the possibility of data trampling must be good! People do have trouble understanding task safety. You can say of a library "this [xxx] is not task-safe", but then they go and access it from multiple tasks anyway. So you arrange that concurrent read-only access is OK - and it turns out that they are modifying the thing from another (set of) tasks at the same time! I googled typestate encoding, the description at [1] leaves me a bit baffled, as well as wondering whether the Rust guys find Ada syntax and style as puzzling as theirs does me. However! I see that my link is to embedded Rust, clearly I ought to look at that. [1] https://rust-embedded.github.io/book/static-guarantees/typestate-programming.html