D has become unbearable and it needs to stop

[Dukc]

On Thursday, 8 June 2023 at 14:33:57 UTC, GrimMaple wrote:
> On Thursday, 8 June 2023 at 13:54:53 UTC, FeepingCreature wrote:
>> Can't confirm. Can you give some examples, please? In my 
>> experience (and we maintain a lot of D code), serious *new* 
>> breakage (not an existing bug) is pretty rare.
>>
>> To be fair, we don't use that many external libs though.
>
> 2.104 deprecated `ref in`, this changes function signatures 
> (Adam was particularly displeased with having to push breaking 
> changes).
> 2.103 deprecated `alias this` on classes, which resulted in 
> complete code breakage. This lad 
> https://github.com/FreeSlave/icontheme/issues/2 even refused to 
> do anything about it.
> 2.102 deprecated `__traits(getAttributes)`. Somebody complained 
> about this, but I can't remember who exactly. Probably Adam 
> again.
> 2.101 removed `std.xml`, which led to a significant rewrite of 
> dlangui, which inevitably led to me leaving D (even though 
> temporarily). And no, `undeaD` maintainers refused to fix my 
> problems: https://github.com/dlang/undeaD/pull/54 , 
> https://github.com/buggins/dlangui/issues/643 (tl;dr undeaD 
> doesn't work with GDC)
>
> Other versions go too far back for my memory

This list demonstrates you aren't complaining for nothing. It's 
easy to see dealing with this rate of breakage it is painful.

That being said, I don't think language instability is the 
problem. We want D to develop after all, and the language already 
tries to be reasonably backwards-compatible. It's just the 
natural price of using a language that is still developing.

Bundling changes to fewer releases wouldn't probably help either. 
We'd have version changes less often, but they'd be bigger when 
they do happen. If anything, we should have a common agreement of 
what is the latest "LTS" compiler verion a DUB library should 
support. I don't mean the compiler would have any LTS support 
from it's development team, just that it'd be the verion DUB 
libraries are tested against.

Fortunately there are ways for the user to ease the pain. The 
common theme in your list seems to be you're relying in many 
libraries. I don't know how many, and I'm not saying it's wrong. 
But the less library dependencies you have, the less problems.

Sometimes it may be more practical to bundle the library source 
in your codebase (as opposed to DUB registry) so you can fix it 
yourself. That has its downsides but it's still a valid choice.

Also, unless it's something security critical such as certain 
parts of Vibe.d there is no pressure for libraries to be up to 
date. You can use older library versions until everything is 
ready to update to newer compiler version.