www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The ensloppification of D is a grave mistake

reply solidstate1991 <laszloszeremi outlook.com> writes:
Setting aside artists' concerns about genAI automating away part 
of the human experience, setting aside environmental issues such 
as water and electricity usage, setting aside social issues such 
as the accessibility of creating propaganda in large amount, even 
setting aside issues from code quality, which all will drive away 
potential users from the D ecosystem, there's still one issue: 
licensing.

GenAI models has been trained on the internet. They tried to vet 
it, yet again and again things are slipping through the cracks. 
This means code that licensed GPL is in the training material, 
and sometimes it can resemble the original code very closely, see 
the FreeBSD exFAT driver, that was a bit less stable regeneration 
of the Linux exFAT driver hacked onto FreeBSD. Even worse is, 
that on the internet, we have both "source code viewable" type 
solutions, and source code that has been acquired through dubious 
means, to be then shared illegally without the consent of the 
original writers.

On one hand, this creates a legal minefield for us, possibly 
forcing us into a lawsuit, or to relicense Phobos, ending with 
relicensing every later D applications. On the other hand, it can 
help to erode the social contract around open source.

Even if we get over these issues, there's the problem of code 
quality. Sometimes vibe coded applications pass basic safety 
checks, but then real-life tests prove those otherwise, and the 
code is overinflated with extra lines and extra unnecessary 
tricks. Sure, it might amaze the intended audience, business 
people who either invest or were told they'd be the next 
generation of programmers, but in the long-run, it will just 
result with extra lines. GenAI code also led to an epidemic of 
"library slop": libraries created just because someone could, not 
because of someone needed them. Every time I thought of making a 
new library, I checked what's available rather than diving deep 
into making them myself. Now the new standard is making 
everything yourself just because it's more trendy that way.

I therefore demand to stop adopting LLM usage for the development 
of the standard library at least, but I would be extra thankful 
if the D Language Foundation could do a 180 degree turn on LLM 
adoption. As a heads up on that front: the Rust community tries 
its best to hide the language's adoption of core functional 
programming features as defaults, and now they try to market them 
as "common sense features" to distance themselves from the issues 
the functional programming paradigm might cause in some 
instances, such as in game development, no matter how much toxic 
positivity does the Rust community spread about the language and 
Bevy. At this moment, it would be easy to do so.

I understand it. I born in the nineties, and I had some family 
members who got afraid I might get addicted to this fancy new toy 
called "computer" to the point that after a while, I won't be 
satisfied by GTA or Doom, but by getting a machine gun from the 
black market, then shoot up my school. Others were concerned, 
that corporations might drop computers, because "they like to 
crash constantly". Yet others were concerned that I might be 
secretly a sports star, and the computer is the reason why I 
don't give it a real try. But I also remember the countless 
technologies that did not get adapted by the end, at least to the 
degree some people wanted. And there are also technologies being 
trashed solely because something fancier-looking exists, such as 
physical media.

I don't want to leave, but things might force me to do so. Every 
other alternative, thanks to the success of Rust, is OCaml with 
curly braces for scope delimiting. D even lets me to have two 
kinds of memory management at once, while all other languages try 
to limit themselves to a few select tools, and force their users 
to follow "best practices" like functional programming. I also 
fear, that this will on-par with the disaster of D1 vs. D2 and 
Phobos vs. Tango.

signed: László Szerémi / ShapeshiftingLizard / ZILtoid1991 ( 
ziltoid1991 proton.me )
Jul 03
next sibling parent reply Adam Wilson <flyboynw gmail.com> writes:
On Friday, 3 July 2026 at 10:55:19 UTC, solidstate1991 wrote:

 On one hand, this creates a legal minefield for us, possibly 
 forcing us into a lawsuit, or to relicense Phobos, ending with 
 relicensing every later D applications. On the other hand, it 
 can help to erode the social contract around open source.


IANAL, but yes, there is a possibility of a legal issues ahead 
for LLM's. However, I would ask, do you not think that some of 
the best legal minds in the world have spent untold numbers of 
hours asking all these questions already? With the benefit of 
being actual legal scholars?

I also think you seriously underestimate how conservative the 
legal departments at tech corps tend to be. If I may share a 
story from my time at Microsoft:

I wanted to add an OSS library to our project. It was one of the 
licenses Microsoft allows, solved a huge problem for my team, and 
most importantly was already used extensively inside Microsoft on 
other teams. I needed my bosses approval, his bosses approval, 
and once I had those, I had to spend a day completing 
paperwork... For a library that Microsoft already used internally.

That is how risk-averse the average corporate legal department is.

Do you really think a legal department would allow a 
multi-trillion dollar company to blindly run into the biggest 
potential legal minefield in decades without first having at 
least spent a few man-decades of time figuring out all the ways 
to NOT step on a mine?

There is one potential risk vector for Phobos I can see, and that 
is someone being sued for using Phobos in their product. This is 
possible, however, there are no such lawsuits currently in 
progress. All LLM related lawsuits at the moment are targeted at 
the tools themselves. Thus the risk remains entirely theoretical 
at present.

I am not saying that their are **NO** risks, but what I am saying 
that you are most likely significantly over-estimating the legal 
risk here.

Again, IANAL.

I would note that the biggest OSS organization in the world by 
number of active devs, the Linux Foundation, is not only actively 
incorporating large volumes of LLM generated code into the Linux 
kernel, they are considering [removing all LLM attribution 
requirements](https://www.phoronix.com/news/Linux-AI-Attribution-Again),
because realistically, nobody actually cares how the code was created, only
that the code meets their quality metrics. If the LF is legally unconcerned
then I see no reason why an org as small and penniless as D should be more
concerned.


 I therefore demand to stop adopting LLM usage for the 
 development of the standard library at least, but I would be 
 extra thankful if the D Language Foundation could do a 180 
 degree turn on LLM adoption.


I am going to be blunt. There is a sort of naive hauteur required 
to make such a demand.

Your post approaches this topic as though, we the community, must 
immediately acquiesce to your demand without any further 
consideration of the topic. As best I can tell you are making 
this demand because you have determined that your position is the 
only valid moral/ethical/legal position and any further 
discussion on the merits is therefore rendered moot. This is a 
highly unprofessional way to approach a deeply sensitive topic as 
it presumes that you, and those with whom you agree, are the sole 
arbiters of what is moral/ethical/legal and all other positions 
are *prima facie* immoral/unethical/illegal because you have 
determined it to be so.

Instead of making demands, I would strongly encourage you to 
engage in the discourse on the topic with an open mind and a 
learner's heart.

You may of course choose to leave, and there are a handful of 
languages that may meet your requirements. But if the D community 
chooses to allow LLM's then that is the community's choice and 
you do not have the right to demand otherwise.

Which gets to my last point. In my opinion, your demand of the 
DLF is misplaced. For the entire duration of my time in the D 
community, the community has always determined the direction of 
the DLF, and not the other way around. Therefore it is the 
community to whom you should be directing your demand. Not the 
DLF.

---------

Nothing in this post represents or is intended to represent the 
official position of the DLF. These are my thoughts, and my 
thoughts alone, on this topic.
Jul 04
parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Sunday, 5 July 2026 at 03:20:10 UTC, Adam Wilson wrote:

 because realistically, nobody actually cares how the code was 
 created


As far as I can tell Im the moderate, (*I dont like that*,) I 
think there was a forum post declaring the use of ai was a "grave 
mistake" maybe we could look it up, that person probably cares.

There should be an open letter floating around stating otherwise; 
its honestly 50/50.
Jul 04
parent reply Adam Wilson <flyboynw gmail.com> writes:
On Sunday, 5 July 2026 at 03:32:34 UTC, monkyyy wrote:

 On Sunday, 5 July 2026 at 03:20:10 UTC, Adam Wilson wrote:

 because realistically, nobody actually cares how the code was 
 created


 As far as I can tell Im the moderate, (*I dont like that*,) I 
 think there was a forum post declaring the use of ai was a 
 "grave mistake" maybe we could look it up, that person probably 
 cares.

 There should be an open letter floating around stating 
 otherwise; its honestly 50/50.


For context, I was speaking about the Linux Foundation. I thus 
amend that sentence to state "nobody *at the Linux Foundation* 
actually cares how the code was created."
Jul 04
parent monkyyy <crazymonkyyy gmail.com> writes:
On Sunday, 5 July 2026 at 03:45:18 UTC, Adam Wilson wrote:

 On Sunday, 5 July 2026 at 03:32:34 UTC, monkyyy wrote:

 On Sunday, 5 July 2026 at 03:20:10 UTC, Adam Wilson wrote:

 because realistically, nobody actually cares how the code was 
 created


 As far as I can tell Im the moderate, (*I dont like that*,) I 
 think there was a forum post declaring the use of ai was a 
 "grave mistake" maybe we could look it up, that person 
 probably cares.

 There should be an open letter floating around stating 
 otherwise; its honestly 50/50.


 For context, I was speaking about the Linux Foundation. I thus 
 amend that sentence to state "nobody *at the Linux Foundation* 
 actually cares how the code was created."


I bet there's plenty of drama in the d's newspaper of record, 
hackernews.

If we amending statements that are intentionally misleading, in 
light of 2 open letters, I would append my dip to *not* be about 
the legal concerns, that was me pushing safetyism buttons.

The ai question will need to be addressed tho.
Jul 04
prev sibling parent reply Anton Pastukhov <mail anton9.com> writes:
On Friday, 3 July 2026 at 10:55:19 UTC, solidstate1991 wrote:

 Setting aside artists' concerns about genAI automating away 
 part of the human experience, setting aside environmental 
 issues such as water and electricity usage, setting aside 
 social issues such as the accessibility of creating propaganda 
 in large amount, even setting aside issues from code quality, 
 which all will drive away potential users from the D ecosystem, 
 there's still one issue: licensing.


Wait, do D compilers and tools use LLMs extensively, in the full 
vibe-coding mode?
Jul 05
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 05/07/2026 10:46 PM, Anton Pastukhov wrote:

 On Friday, 3 July 2026 at 10:55:19 UTC, solidstate1991 wrote:

 Setting aside artists' concerns about genAI automating away part of 
 the human experience, setting aside environmental issues such as water 
 and electricity usage, setting aside social issues such as the 
 accessibility of creating propaganda in large amount, even setting 
 aside issues from code quality, which all will drive away potential 
 users from the D ecosystem, there's still one issue: licensing.


 
 Wait, do D compilers and tools use LLMs extensively, in the full vibe- 
 coding mode?


No.

Nothing even remotely like that.

Just some bug fixes here and there that all get reviewed as if LLM's 
weren't involved.
Jul 05
parent reply Anton Pastukhov <mail anton9.com> writes:
On Sunday, 5 July 2026 at 10:48:57 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 On 05/07/2026 10:46 PM, Anton Pastukhov wrote:



 No.

 Nothing even remotely like that.

 Just some bug fixes here and there that all get reviewed as if 
 LLM's weren't involved.


That is... totally fine? I hate vibe coding as much as the next 
guy, but, given D's constant lack of manpower, using clankers for 
menial tasks should be OK.
Jul 05
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 05/07/2026 11:19 PM, Anton Pastukhov wrote:

 On Sunday, 5 July 2026 at 10:48:57 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 On 05/07/2026 10:46 PM, Anton Pastukhov wrote:


 

 No.

 Nothing even remotely like that.

 Just some bug fixes here and there that all get reviewed as if LLM's 
 weren't involved.


 
 That is... totally fine? I hate vibe coding as much as the next guy, 
 but, given D's constant lack of manpower, using clankers for menial 
 tasks should be OK.


Yeah.

There are somethings in the pipeline like arm inline assembler for dmd, 
and codeview update.

Those are bigger, but nothing big that has been merged that I am aware of.
Jul 05
parent Adam Wilson <flyboynw gmail.com> writes:
On Sunday, 5 July 2026 at 11:22:33 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 On 05/07/2026 11:19 PM, Anton Pastukhov wrote:

 That is... totally fine? I hate vibe coding as much as the 
 next guy, but, given D's constant lack of manpower, using 
 clankers for menial tasks should be OK.


 Yeah.

 There are somethings in the pipeline like arm inline assembler 
 for dmd, and codeview update.

 Those are bigger, but nothing big that has been merged that I 
 am aware of.


This run through the installers I've been been on to get FreeBSD, 
UCRT, and the nightlies working has been primarily LLM driven. 
I've done a little bit by hand where it was simple enough not to 
justify spending the money.

For the most part the LLM's have been handling these tasks quite 
well.
Jul 05