> Elimination of memory problems is much more valuable than detection. Recovering from memory errors at run time is unreliable.

I'm not sure but I have a gut feeling that I am just in a position that is not good to defend. I want small software that fails hard on weak causes, and the industry wants software that fails soft on strong causes. I cannot win any argument and will, as hobbyist who likes elegant code, face frustration after frustration, admittedly in all digital products, not only compilers.

I'm sure you're right. Elimination of memory problems is what must be provided. I agree.

> The advantage of D is that all options are open. This allows the following approach:
> ...
> ...
> This makes starting a project in D a safe choice, in multiple meanings of the word.
>
> — Bastiaan.

Thanks! :) Well, in the end, there should be a way like this.

>> Recovering from memory errors at run time is unreliable.

I should add that I have more like a romantic view of software release cycles where testing is done until the software is in a very, very sophisticated and stable state. More than usual.

Not that I want to solely rely on such an approach. It should still try to recover from failures, and recovering should be trained like fire fighting is trained. But there should be no smokers in the building, so to speak.

On Sunday, 29 November 2020 at 19:09:07 UTC, Mark wrote:
>> Looking at Ada now.
>
> I found: Ada is not good for me. It has no augmented assignment. It's just that I want DRY because I use very verbose variable names

Using a reasonable naming convention should be much easier than looking for a perfect custom language. Well, another variant is zig, which was supposed to be C but safe.