On Thursday, 8 June 2023 at 17:20:25 UTC, Johan wrote:

Personally I only use GDC in production and I've never had any surprises with their releases, I honestly would never use DMD in production I consider the quality of the backend insufficient for serious use in production.
I don't want to say a heresy, but sincerely if I had to decide for D the first thing I would do is stop work on DMD I don't see the real usefulness when we have LDC and GDC. Probably the primary development could be done on LDC to not have to be conditioned by the release times of GCC.

On Thursday, 8 June 2023 at 16:13:54 UTC, GrimMaple wrote:

Fully agree! and I also suggested over and over again to separate D2 and D3 for a long time.

And as another evidence: just look at how fast this threads grow: 30 replies in ~3 hours!

Me too, it's much more like a hobbyist project.

@Walter, do you hear?

On Thursday, 8 June 2023 at 15:38:15 UTC, Mike Parker wrote:

Too much bureaucracy: just look at:

1. How fast this threads grow: 30 replies in ~3 hours! esp. from developers who are maintaining real projects.

2. And, how many times this topic have been raised in this forum again and again.

On Thursday, 8 June 2023 at 17:49:27 UTC, mw wrote:

I am a developer who maintains real (commercial!) projects, and I want D to break more compatibility and do less stability. Just, you know, for reference.

Every time a complaint threat comes up, it tends to hog the frontpage. This sort of forum mechanics selects for engagement, not agreement. Note how my responses disagreeing with you bump the thread just as much as responses that agree.

Also, at the end of the day, language development is not a poll. There are some good arguments for (and against) a D3 split; "look how many posts can get spammed on this thread" is not one of them. Otherwise we should probably go and make private class scope as well...

On Thursday, 8 June 2023 at 13:38:20 UTC, GrimMaple wrote:

For facing reality, there is a bunch of code that were made in dlangui with a lot older version of the language. And right now, I don't see as much breakage as it happens with dlangui. There is a bunch of stuff that is being workarounded every version.

For Hipreme Engine, I do get some errors on users when they use a different version, what I've done is simply limiting their version (my build system also includes an auto download system for the expected D version). I'm always trying to stick to the most recent version because i know that if I stick too much time with a version, when needing to jump 10 versions, everything will be broken (specially since I'm maintaining my own runtime now).

The thing is that D doesn't have structure enough to get a LTS.
We can only try to always get newest ones because we don't want to deal with old and nasty bugs.

What I see right now is that D is in a constantly changing phase where they're trying to fix those billion bugs we had on bugzilla so it is quite normal to expect there will be a lot of breakage in this trail.

So, what I would recommend right now is literally adding more examples to buildkite and adding migration paths. Which would be a lot easier than maintaining 2 versions of the language (which I find rather unproductive most of the time)

On Thursday, 8 June 2023 at 14:33:57 UTC, GrimMaple wrote:

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.

On Thursday, 8 June 2023 at 19:34:41 UTC, FeepingCreature wrote:

Maintaining closed-source commerical projects isn't a problem with changing compiler. Because you only need to support one version at a time. Then, try writing open-source with many users, all of whom use different versions (and vendors) of compiler. Now you're in trouble.

D3 split doesn't hurt anyone. I don't know about making private class scope. If it doesn't hurt people - why not. After all, the "support" of an LTS branch will most likely go towards those interested in that branch, while others can use D3 if they want breaking changes.

Of course it's not a poll, but if issues come up repeatedly, then you have to listen to them. I don't understand how LTS is such a bad idea that everyone is so aggressively against it. It's not like we're stealing your freedom to do whatever, we're proposing (or at least trying to) a solution that theoretically should fulfill both ends needs.

As someone in this thread pointed out already, LTS doesn't really require a lot of work to begin with. Just fix behavior in-place, with occasional security and segfault patches. At least, a working strategy could be developed according to amount of manpower.

Also, "D doesn't have structure" isn't coming from the nature of things. It has no structure because nobody is giving it structure.

I also find it very amusing how, supposedly, Walter has a final say anyway, but it's always the community's fault for D lacking structure, or manpower, or anything else.

I would've liked to see a negotiation point from the D core team, like: "We can do an LTS branch, if: #list requirments here#". So we can allocate people, assign roles, maybe even raise funds. But I hate it when core devs just show up saying "nah can't be bothered you do it". Because I know, at the end of the day, Walter can just say "no" and all the effort will go down the drain.

I find the whole idea of LTS pointless when the core community isn't interested in working towards that goal. I mean, if the initial author of LTS leaves, what are you stuck with?