Why static analysis is the way to go

[monkyyy]

On Thursday, 28 May 2026 at 19:41:27 UTC, H. S. Teoh wrote:
> Preaching to the choir here, but this again shows why static 
> analysis and compiler-enforced checks at compile-time is the 
> way to go:
>
> https://www.zdnet.com/article/rust-will-save-linux-from-ai-says-greg-kroah-hartman/
>
> The Linux kernel is a pretty large C codebase, and I also work 
> with a pretty large C codebase in my day job.  At that scale, 
> the weaknesses of C persistently come up: forgetting to free a 
> pointer after use, forgetting to release a resource (often in a 
> rare path not often or never tested), buffer overruns, dangling 
> pointers, etc..  After decades of working on a large complex C 
> codebase, I've grown weary of debugging these same old problems 
> over, and over, and over again.
>
> D made a lot of right choices in this area: 
> statically-verifiable const, compiler-enforced nothrow, pure, 
> etc., arrays that always carry length and out-of-bounds 
> deference causing a runtime exception instead of overwriting 
> arbitrary memory, GC eliminating an entire class of pointer 
> bugs, etc..  These make D a huge pleasure to work with, as 
> opposed to the constant stream of pointer bugs, memory leaks, 
> and programming-by-convention that has been proven to be 
> ineffective decades ago, that you have to put up with when 
> working in C.
>
>
> T

99.99% of the effect is api and type theory: slices being built 
and foreach being overloadable with ranges, ranges being there

This is not static analysis, I dont use any static analysis 
keywords that would cause any of it to be inside my code, yet Im 
not running into c like segfaults every time I write string code

Hot take, 70% of it of my avoidance of segfault comes from 
foreach being able to use range alone; if Phobos wasn't there but 
the way I made datastructures was front,pop, empty; I would not 
make segfaults.