@MSGID: 1@dont-email.me> 3e62d0eb
@REPLY: 1@dont-email.me> 11cd4212
@REPLYADDR G.B. <bauhaus@notmyhomepage.invalid>
@REPLYTO 2:5075/128 G.B.
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 1@dont-email.me>
@RFC-References: 1@dont-email.me>
1@dont-email.me> 1@dont-email.me> 1@dont-email.me>
@RFC-Reply-To: nonlegitur@notmyhomepage.de
@TZUTC: 0200
@PID: Mozilla/5.0 (Macintosh; Intel Mac OS X
10.15; rv:102.0) Gecko/20100101 Thunderbird/102.15.1
@TID: FIDOGATE-5.12-ge4e8b94
On 25.09.23 12:38, J-P. Rosen wrote:
> Le 25/09/2023 ? 11:59, St?phane Rivi?re a ?crit :
>>> How long before they relax the requirements
>>> and idiots say "we can use C again, yay!"?
>> By the time they discover Rust ?
> 
 > Or when they realize that there is only one rust compiler, and
therefore that a single compiler virus could ruin the whole defense system.
> 

Maybe, given the emphasis on tools, verification and best
practices, they might consider sub-languages, or profiles,
of several existing languages.

It`s not like memory-safety cannot be made available in
languages other than Rust, I should think? Though, it seems
to me that Rust has so much better market-aware development
strategies than any other language since C, outside Microsoft`s
or Apple`s areas of sales.

Also, I understand that Linux kernel development is
steered towards Rust and LLVM. So, they have decided
not to go back to the 80s, just pick some good bits
and move on, possibly producing grust or crust while
at it.

In order to pick well from Ada and the concepts embodied in it,
imagine what parts of Ada should be thrown out,
ignoring commercial enterprises living off legacy business?
What changes to Ada are a good fit while aiming
at memory safety, verification support,
or light weight and safe parallel execution?

As you can see in [1], there is a suggestion to make money
available to refactoring efforts.

  [1]: https://www.federalregister.gov/d/2023-17239/p-37

 --- Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.15.1
 * Origin: A noiseless patient Spider (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441