Why static analysis is the way to go

[H. S. Teoh]

On Fri, May 29, 2026 at 01:11:02AM +0000, monkyyy via Digitalmars-d wrote:
[...]
> Im asserting I write smaller programs then most, without @safe,
> without and debugger, using compiler bugs, void* whenever I want and I
> do not have memory management issues that rust and c++ smart pointers
> and allocators and gc debates claim is a hard problem. Because I do
> one thing: I push the blame to the datastructure where it belongs.
> When I call opIndex on my data structures I ussally make a small hack
> to make it return something; then I use that opIndex to make a range.

Well, that explains a lot. :-D  If you mostly write one-man-show small
programs, none of these things are even an issue.  Have a dangling
pointer?  No problem, kill the process, restart from clean slate.  Have
a memory leak?  No problem, the program will exit soon, OS will clean up
for you.  Memory corruption?  No problem, the worst case scenario is the
program crashes, OS cleans up, program restarts.

I write a fair amount of small D programs as helper utilities, and yeah
for those I throw all care to the winds, allocate as much as I want, GC
will clean up.  Cast size_t to int, cast void* to whatever*, doesn't
matter.  Get the job done before the boss fires you, good enough.
Produce output before the program corrupts itself into a bad state, good
enough.

But if you're writing a long-running daemon running in the background,
or an embedded system doing complex processing that cannot afford to
crash, because customer data must not be lost, then these issues become
big problems.  You cannot afford memory corruption, because it might
contain sensitive customer data. You cannot afford dangling pointers,
because some bot online might exploit that to run arbitrary code and
break into your customer's corporate network.  You can't afford wasteful
memory usage, because you might run out of memory and crash in the
middle of customer's production operations and lose customer data.

We are not the same. :-D  lol


> My code is very very unsafe; but I just dont have these issues people
> keep claiming are very hard to solve around memory. By going in the
> exact opposite direction from rust.

In your use case, no kidding, Rust is total overkill.  It's like
detonating a nuclear warhead to kill an ant.  Completely unnecessary,
and doesn't make sense economically.


> > You're missing the point. C++ iterators, frankly, stink.  I used to
> > write a fair amount of C++, and iterators just suck so hard compared
> > to D ranges.
> 
> > But they're a step up from C++ iterators.
> 
> The *type theory* is the identical as far as I remember, only the api
> is different, and if you go full iterator you would get the same
> benefits of going full range.

Semantically C++ iterators are actually more powerful than D's.

Ergonomically?  D ranges win hands down.  Cleaner API, less weird edge
cases, less likelihood of wrong usage, less boilerplate needed to get
useful things done, etc..


[...]
> > (This doesn't mean I don't care about memory management --
> > optimizing bottlenecks require you to take over the reins from the
> > GC sometimes, and I'm fine with doing that, and have done it on
> > occasion.  In fact I appreciate how D lets me control memory
> > management to the point I can call malloc/free myself if I really
> > wanted to.  But I shouldn't be *required* to think about memory
> > management left, right, and center every other line of code I write.
> > That's just ridiculous.)
> 
> You should care even less.

lol for my one-off shell-script replacement D programs, yeah totally, I
don't even think about memory management or type safety.  As long as it
works and produces the right output, who cares how it got there.  The OS
cleans up the dirty laundry afterwards anyway, no big deal.

Different story when I'm writing a window manager.  Doing something
stupid like an unsafe pointer cast can bring down my entire work
session.  Not fun.

Or when I'm writing compute-intensive complex computations.  Bad memory
management / bad or lack of optimization can mean the difference between
getting the answer 2 hours later, vs. 2 *months* later.  Big difference.
(Or in worse cases 2 years later. Or 20 years if you're stupid about
exponential algorithms.  Or maybe 200 years if you're *really* stupid
about it.  Beware Shlemiel.)


T

-- 
Fact is stranger than fiction.