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: "Alejandro R. Mosteo" Newsgroups: comp.lang.ada Subject: Re: Microsoft is considering moving to Rust; potential opportunity for Ada2020 Date: Thu, 8 Aug 2019 11:25:20 +0200 Organization: A noiseless patient Spider Message-ID: References: <01e1fc91-a20e-4b48-a10e-57d3935cd06c@googlegroups.com> <0d4e46d4-c227-4d7a-aafa-44492c6e1d41@googlegroups.com> <871ryop74h.fsf@nightsong.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Thu, 8 Aug 2019 09:25:21 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="ba358395170d116922fe57feefc712e3"; logging-data="24773"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18tQLQJYgMEv7jqC7BmBQzB" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 Cancel-Lock: sha1:7yciORvsR+IGoGhDGeXhoUPO4kQ= In-Reply-To: Content-Language: en-US Xref: reader01.eternal-september.org comp.lang.ada:57008 Date: 2019-08-08T11:25:20+02:00 List-Id: On 8/8/19 4:13, Jere wrote: > On Wednesday, August 7, 2019 at 5:09:06 AM UTC-4, Alejandro R. Mosteo wrote: >> On 6/8/19 19:49, Brad Moore wrote: >> >>> I believe it is also not just related to concurrency. For example, if you pass a pointer to an object into a function which deletes the object, the compiler will detect that use of that pointer after calling the function is not allowed. >> >> Yes; concurrency safety (in a limited sense) is the side-effect, not the >> main point, I'd say. > > I think at some point before the language was first stabilized (2015), > both were actively pursued. Here are some musings from the original main > developer back in 2013ish [1]. Later on, another Mozilla developer also > talked about a similar topic [2]. > > [1]: http://smallcultfollowing.com/babysteps/blog/2013/06/11/on-the-connection-between-memory-management-and-data-race-freedom/ > [2]: https://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/ > > It is interesting that both of them kind of hint at the idea of a large > single threaded program having similar challenges to a multithreaded > program, at least when considering how undefined behavior, data > invalidation, and data races occur. I understand better now; thanks for these references.