So it is happening,

"Memory issues in software comprise a large portion of the exploitable vulnerabilities in
existence. NSA advises organizations to consider making a strategic shift from
programming languages that provide little or no inherent memory protection, such as
C/C++, to a memory safe language when possible. Some examples of memory safe
languages are C#, Go, Java, Ruby™, and Swift®."

https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF

Eventually this will move from a recomendation, to possible specific certification requirements to still deliver software in such languages.

D is not yet on the list, but who knows, it might make an appearance on some revised version, if someone at NSA is paying attention.

On Friday, 11 November 2022 at 07:03:58 UTC, Paulo Pinto wrote:

The conspiracy continues

On Friday, 11 November 2022 at 07:03:58 UTC, Paulo Pinto wrote:

I find it more surprising that Python is not on the list. But they just provide a few examples of safe programming languages.

But even if they decide to provide a complete list of recommended programming languages, in NSA's shoes I would avoid recommending D yet. Because is not @safe by default and the @system code in "-release" builds has no bounds checking (so goodbye memory safety). Additionally, catching arithmetic overflows is the next safety frontier NSA may be looking into and D has nothing good to offer (the checkedint library is a fig leaf and non-practical in reality).

On Friday, 11 November 2022 at 08:34:39 UTC, Siarhei Siamashka wrote:

The document has references about MSLs. The quote from one of them:
The workshop consensus was that the Rust programming language, despite its initial learning curve, is particularly well-suited for safe systems-level development, even where performance requirements are important. Where performance requirements are less stringent, languages with garbage collection (GC), such as Java, Python, or Go, may be easier/simpler to use. Toolchains can encourage wider adoption of MSLs for programs, and thus, funding should be driven to the development of tools for MSLs. High performance MSLs like Rust should be well funded and enhanced with more tooling (e.g., static analysis tools, C2RUST converters, compiler plug-ins that facilitate translation to Rust/WASM), to make its ecosystem more robust.

I think it could satisfy the broad definition of MSL:
Even with a memory safe language, memory management is not entirely memory safe. Most memory safe languages recognize that software sometimes needs to perform an unsafe memory management function to accomplish certain tasks. As a result, classes or functions are available that are recognized as non-memory safe and allow the programmer to perform a potentially unsafe memory management task. Some languages require anything memory unsafe to be explicitly annotated as such to make the programmer and any reviewers of the program aware that it is unsafe. Memory safe languages can also use libraries written in non-memory safe languages and thus can contain unsafe memory functionality. Although these ways of including memory unsafe mechanisms subvert the inherent memory safety, they help to localize where memory problems could exist, allowing for extra scrutiny on those sections of code.

On Friday, 11 November 2022 at 08:52:46 UTC, Sergey wrote:

Yes, NSA could list D language provisionally. But there are still many unresolved memory safety issues in D ecosystem in practice. Many dub packages and even Phobos are not compatible with @safe yet. A very simple example:

@safe:
import std.stdio;
void main() { readln; }

$ dmd test.d
test.d(3): Error: `@safe` function `D main` cannot call `@system` function `std.stdio.readln!string.readln`
/usr/lib/dmd/2.099/import/std/stdio.d(4566): `std.stdio.readln!string.readln` is declared here

Without actual @safe annotations already in place, a lot of the existing D code is not really safe. It's surely safer than C/C++, but this not good enough to convince those who are in charge of making programming language choice decisions in companies.

Just imagine that somebody is responsible for buying, let's say, parachutes to replace their existing notoriously unreliable brand. Given a choice between cheaper/convenient (similar to D) and more reliable (similar to Rust) parachute types, what will this person decide to buy for his team? Keep in mind that any future fatal accidents will be surely blamed on this person in the case if he decides in favor of a cheaper option...

TL;DR; You can't really sell a half baked safety nowadays.

On Friday, 11 November 2022 at 08:34:39 UTC, Siarhei Siamashka wrote:

Just declare main @safe.

Either:

1. Don't use -release if safety is a higher priority than performance.
2. Use -boundscheck=on
   https://dlang.org/dmd-windows.html#switch-boundscheck

Memory unsafety is non deterministic. Overflow/underflow is, so it's much less important.

On Friday, 11 November 2022 at 09:32:23 UTC, Siarhei Siamashka wrote:

@safe:
import std.stdio;
void main() { readln; }

$ dmd test.d
test.d(3): Error: `@safe` function `D main` cannot call `@system` function `std.stdio.readln!string.readln`
/usr/lib/dmd/2.099/import/std/stdio.d(4566): `std.stdio.readln!string.readln` is declared here

I have been involved in high safety applications where human life is at risk.
We use C and C++.

The language is not what determines it, it is the tools, processes and organization.

I have done this for over 10 years, developing safety critical software and also as a control systems engineer. Both industrial and mobile applications.

The language is not what is important. It is everything surrounding it.

Have you been involved in any high SIL or PL development? I have, also for railway.

I know what it takes to make something. Also proven in use is important.

On Friday, 11 November 2022 at 14:52:51 UTC, Nick Treleaven wrote:

Have you missed my comment, which was talking about exactly that?

Neither is deterministic. Unless you have strictly deterministic input data.

On Friday, 11 November 2022 at 16:07:15 UTC, Siarhei Siamashka wrote:

Your comment seems to miss the point. By declaring main @safe, you are ruling out various pieces of the language that are unsafe, which is exactly what you want if safety is the priority. You are arguing instead that @safe doesn't work because it prevents you from doing something that is potentially unsafe.

On Friday, 11 November 2022 at 16:07:15 UTC, Siarhei Siamashka wrote:

You didn't mention main.

Whatever the input data, without memory safety you can't trigger the bug through testing alone. It might never occur on your system, only on your client's. That's why the NSA recognises memory safety bugs as categorically worse than logic bugs or overflow/underflow.