How Effectively Agents Write D

[strawberry9]

On Sunday, 8 November 2026 at 03:36:14 UTC, H. S. Teoh wrote:
> 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

Fair enough, but your assertions are premised on .. "having a 
good number of years writing D under my belt..".

To put your assertions to the test, you need someone (or an LLM) 
to be able to assert the same as you, with no previous existing 
knowledge of the D language.

An LLM almost certainly knows a great deal more about coding in 
Go than D (due to its training set), so it will very likely 
require more effort in D compared to Go.

An LLM knows nothing about CobaltC until I introduce it to the 
agent. So I can examine these claims in a much cleaner research 
context (although CobaltC has some similarity to Rust which seems 
to help the agent a lot as well, since it clearly alreadys knows 
a lot about Rust).

btw. I also instruct my agent to create a findings.txt for every 
program it writes, in which it tells me about the 
problems/difficulties it had in constructing the particular 
program at hand. That could be a worthwhile thing to do if you 
have it programming in D as well. Of course nobody uses CobaltC 
yet so I am free to incorporate the agents feedback, back into 
the language design. D doesn't have that luxury, so you will need 
to create materials that assist the agent so that it doesn't 
constantly encounter the same issues.