How Effectively Agents Write D

[H. S. Teoh]

On Sun, Nov 08, 2026 at 02:21:22AM +0000, strawberry9 via Digitalmars-d wrote:
[...]
> A genuinely good language makes simple problems simple, complex
> problems manageable, and dangerous mistakes difficult to make.
> 
> C and Rust illustrate this difference in how much responsibility each
> language places on the programmer versus how much it attempts to
> manage through language mechanisms. This was one of the primary
> motivations for me creating CobaltC -
> https://github.com/strawberry9/CobaltC
> 
> My 15 years experience with D's complexity was another motivating
> reason ;-)
> 
> Interestingly I've discovered that LLM's have very little difficulty,
> almost none actually, in writing complex programs in CobaltC, without
> any initial knowledge of it, other than what they can learn from the
> repository itself.
> 
> So the question for D in this new age of AI, is: does D make simple
> problems simple, complex problems manageable, and dangerous mistakes
> difficult to make?

I can't speak on the aspect of AI, but IME so far, having a good number
of years writing D under my belt, is that D strikes a pretty good
balance between ease of use and functionality.  Thanks to modern
conveniences like GC, built-in unittests, and powerful metaprogramming
capabilities like templates (with much saner syntax than C++!), CTFE,
and compile-time introspection, simple problems are definitely simple in
D: I regularly use D as a convenient shell script replacement with saner
syntax and semantics.  And hard problems are tractable where few other
languages manage to -- using CTFE, compile-time introspection, and
little gems like static ctor's, for example, I was able to implement a
simple serialization system that's powerful enough to work with almost
any type -- without any of the usual boilerplate one associates with
serialization -- in about 1000 LOC (including comments and unittests --
without them probably closer to 500 lines or less).

Some of the most dangerous mistakes -- the ones that lead to headlines
in cybersecurity news -- are almost a non-problem in D.  Some of the
most common security flaws that keep coming up in my skimming over OS
security updates is related to memory management: double-free,
use-after-free, buffer overflow.  In D, these are basically a
non-problem thanks to arrays always coming with bounds, and the GC.  And
if you use @safe, you pretty much never have to worry about pointer
bugs.  This cuts out at least 50%, if not more, of the total security
flaws that I keep seeing mentioned in my OS updates.  In D, you almost
have to try hard to get a pointer bug in your code(!).

Another common problem is printf format errors (I work with C code at
work so I probably see these more often than people who don't work
directly with C, so YMMV).  D isn't completely free of problems in this
area, but it does at least have type-safe variadic functions, which
mitigates a large percentage of these issues.

So overall, while D isn't without its spots and wrinkles, I'd say it
fits the bill pretty well.  Simple code remains simple -- almost
shell-script level simplicity.  Hard code is possible -- in fact almost
pleasant unless you happen to need one of those rare things that gets
into one of the dark corners of D -- thanks to powerful metaprogramming
capabilities.  And by default D is already pretty safe from your usual
dangerous mistakes; if you want more protection slap on @safe and it
will keep out even more of them.  Not perfect, but if used properly you
can be pretty confident about the result.

I'd also add that D is almost an anti-boilerplate language.  I almost
never have to write boilerplate code in D; thanks to metaprogramming
almost all of it can be happily automated away, leaving only the meat
and none of the irrelevant trappings.  No other language I know has come
this close to my ideal of what a programming language should be.


--T