D has become unbearable and it needs to stop

[GrimMaple]

On Friday, 9 June 2023 at 10:59:35 UTC, Petar Kirov [ZombineDev] 
wrote:
> What is your vision for LTS releases? How often would a new LTS 
> version be released and for how much time would it be 
> supported? How many LTS branches would be maintained in 
> parallel? Something like the Ubuntu release cycle - 
> https://ubuntu.com/about/release-cycle?
> What is the range of supported versions that you would expect 
> an actively maintained D library to support? Only the oldest 
> LTS, or only newest one? What about the current versions?
> What are the criteria for backporting changes to an LTS branch? 
> While library functionality removals and new compiler errors 
> are obviously a no-no, what about deprecations? On one hand, 
> one would would prefer things to keep working as they were, but 
> on the other hand deprecations are a migration tool - they let 
> the users know that they need to adjust their code in order to 
> be able to upgrade to a new version down the line.

If it were up to me - I'd just split D into D2 and D3. D2 being a 
stable non-breaking lang that only adds upon what it already has. 
And D3 being a playground with "whatever goes", until peopel 
agree it's good enough and split for D4 is required. However, I 
understand other points of view as well, so having _at least_ 
some sort of stable release I am willing to treat as "good 
enough". A two-year cycle is a widely accept practice it seems, 
so why not adopt it?

> There's also the question of certain bug fixes: usually 
> druntime & phobos are straightforward, but there are some 
> compiler bug fixes that can cause surprising regressions that 
> are only discovered years (!) later, despite the best effort of 
> everyone. I can assure you that this is not a theoretical 
> concern - we've had hundreds of regression-causing bug fixes 
> like this. The main cause is that the semantic processing part 
> of the compiler codebase is very complex and convoluted. While 
> some argue that the solution is ground-up from-scratch 
> reimplemtnation (which is what the SDC project that has been 
> years in the making is trying to accomplish), realistically, 
> the most pragmatic option is to continuously refactor the 
> codebase until it becomes much easier to maintain and evolve. 
> Which is exactly what almost every major compiler contributor 
> has worked towards on many occasions, but the reality is that 
> we're still far from the place we want to be, and there's much 
> more work to be done.

I think, in the real world, if you don't add new stuff -- you end 
up with less bugs, provided you fix existing ones. As in, bug 
fixes rarely lead to introducing more bugs, it's the development 
of new features that usually bring new issues. If you localize 
refactorings to a concrete issue - it's not too difficult to 
backport everything. Anything else is, unfortunately, tough luck 
(tm). In my view, an LTS branch should only recieve critical 
bugfixes, such as compiler crashes or security vulnerabilities. 
If something leads to a buggy behavior - that's a thing that 
should be fixed in main branch and released in the next LTS.

> I don't expect the rate of change to decrease, (and I surely 
> hope it doesn't as it means the development is dying!), so I 
> would expect the divergence between the LTS release and the 
> current one to constantly increase, both in terms of direct 
> user-observable language changes, but also in terms of the 
> codebase. There are many cases where in order to fix a bug you 
> first need to refactor the code (so e.g. the logic is 
> centralized in a single place and not spread across multiple 
> files), which would make certain commits very difficult to 
> apply to the LTS branch.

In my opinion, that is only going to happen if D continues do 
develop with no clear goal or target. Lack of understanding where 
D is heading towards is creating that issue almost 
singlehandedly. Of course you're gonna divert the community if 
big changes are going to keep popping out of nowhere, like 
ImportC did. Infact, I think, LTS branch might help bring order 
to somewhat chaotic nature of D development cycle. Provided that 
D wants to have any order, which doesn't seem to be the case. 
Again, it boils down to the fact that D developers (the lang & 
compiler ones) don't really use D on a day-to-day baiss, outside 
of the compiler. So they can't even grasp what I and others are 
talking about. How could they, if their "work" never affects them 
to any extent, they are free to change and break whatever they 
want. They don't have to deal with the damages that they cause.

> And even just in terms of user-facing changes, if the jump from 
> LTS to the current release is too big, upgrading would become 
> much more time consuming than the current status quo of a major 
> release every two months, so in that sense, I would agree with 
> Walter that this has the risk of splitting the community.

It's still the same amount of changes, which are just easier to 
plan ahead for. And, again, it's not the changes themself that 
cause me pain, it's how frequent and breaking they are.

> While the past few releases may have been heavier on the 
> deprecation side of things, once there's a new compiler release 
> with shiny new feature X™, you're quite likely to get an influx 
> of users requesting support for it, so sticking with an old 
> compiler release is unlikely make everyone happy.

The whole __point__ of LTS is that everyone has the same version. 
I have written C++, C#, Obj-C, Java, and many other langs _with_ 
LTS releases and nobody complained about the "recent" compiler 
being unsupported. Because everyone understands why it's called 
an "experimental" version, and they patiently wait for new LTS 
release.