June 10, 2023

On Saturday, 10 June 2023 at 08:58:34 UTC, GrimMaple wrote:

>

Long story short, what is there to discuss, if a simple question like "What are the requirments for the D team to consider LTS branch/release" is hanging unanswered? I don't believe that discussing such a thing is worth my (or anyone else's) time just because nobody cares enough to give straight answers. Without resorting to [please forgive my momentary rudeness] idiotic suggestions to come to some arbitrary meeting to discuss essentially nothing.

I am willing to come to the meeting, fine, but only after some common ground is found on topics of:

  1. Needing LTS in the first place
  2. Requirments and prerequisites for such an event
  3. Your (D team's) proposition on how such thing could be achieved, and what resources are necessary for it

So far I only saw endless debates on wether LTS is even needed, and some abstract talk about "gib monez" without any concrete propositions.

Otherwise, this is a waste of everyone's time.

You're the one pushing for an LTS release. If you have a case to make for it, then you're welcome to come to the meeting and discuss it. I can't speak for everyone on the team. You might find support, you might not. The invitation's there, without any preconditions. Take it or leave it.

June 10, 2023

On Saturday, 10 June 2023 at 09:31:07 UTC, Mike Parker wrote:

>

You're the one pushing for an LTS release. If you have a case to make for it, then you're welcome to come to the meeting and discuss it. I can't speak for everyone on the team. You might find support, you might not. The invitation's there, without any preconditions. Take it or leave it.

With that attitutude, I choose to "leave it".

June 10, 2023
On Friday, 9 June 2023 at 21:13:06 UTC, Richard (Rikki) Andrew Cattermole wrote:
> My general feeling is the LTS should be based upon what is required to bootstrap the compiler.
>

We're already doing that then? It is already a requirement that gdc-9 has to be able to compile gdc-mainline (ergo, dmd itself must always be buildable by 2.076).
June 11, 2023

On Saturday, 10 June 2023 at 10:34:06 UTC, GrimMaple wrote:

>

On Saturday, 10 June 2023 at 09:31:07 UTC, Mike Parker wrote:

>

You're the one pushing for an LTS release. If you have a case to make for it, then you're welcome to come to the meeting and discuss it. I can't speak for everyone on the team. You might find support, you might not. The invitation's there, without any preconditions. Take it or leave it.

With that attitutude, I choose to "leave it".

How come? Mike is saying you're more than welcome to state your case? Are you suggesting that you'll only bother to do so if it's a foregone conclusion that it'll indeed happen?

That seems an odd tack to take for something you apparently feel quite strongly about?

Also, see Iain's message above; 2.076 is already the de facto LTS due to GDC requirements (I believe ADR made this argument recently in the Discord too).

From my limited perspective, the ideal case here is LDC and GDC working together on the de facto LTS versions re. backporting important patches it seems. I'll leave the discussion of how that could work to more knowledgeable people.

In other words: This is really close to happening is my impression. Why wouldn't you want to be one of the people helping to bring it over the goal line re. DLF buy-in so you actually get what you were after in the first place?

June 11, 2023

On Sunday, 11 June 2023 at 19:33:42 UTC, Rune Morling wrote:

>

How come? Mike is saying you're more than welcome to state your case? Are you suggesting that you'll only bother to do so if it's a foregone conclusion that it'll indeed happen?

No. I am suggesting that there is no reason to believe that this "meeting" is going to be productive in any way. What going to happen is, I will join the meeting, and then get reiterated everything that's already been said here. Things like:

>

It's just that I can't see how it would be effective.

If Walter can't see how it would be effective, and actually directly disagreeing with me:

>

Making LTS versions balkanizes the language into multiple languages, which will play hell with 3rd party library maintenance.

How can I convince him otherwise? Just say "no u wrong"? This isn't going to work. Or, rather, why would I even bother convincing him, when a clearly better solution for me would be to simply switch languages. Where I wouldn't even need to support a GUI library to have one.

I have already said that, IMO, to understand my point, core D should try supporting some of the 3rd party. Maybe then they'll have to deal with all that versioning stuff. And maybe then they'll realize that LTS is needed. After all, there are things you can't understand until you're struck by them.

>

That seems an odd tack to take for something you apparently feel quite strongly about?

Some develop the langauge, some use the language. I'm not a language developer, and I don't intend on becoming one. If I wanted to, I'd just make my own language. Because there is only this much resistance I'm willing to go through for free. I have my daily job (in D!), but I'm still willing to commit in ways that can be found productive by both parties. Arguing with Walter isn't something I'm going to do, even for money.
As someone said in this thread previously, D is heavily biased towards language developers, not language users.

>

From my limited perspective, the ideal case here is LDC and GDC working together on the de facto LTS versions re. backporting important patches it seems. I'll leave the discussion of how that could work to more knowledgeable people.

From my limited perspective, GDC is awful and is not good for production. Then again, it's not like any other D compiler is "good enough", maybe LDC is. But anyway, in practice, GDC is a rare beast and most people use DMD/LDC. Maybe if GDC is promoted as "default" D compiler, then yes, we're getting there. But this wasn't suggested by anyone from the D team. They don't even want to spend 5 to 10 minutes coming up with ideas on my direct question:

>

What is your take, what will allow us to have an LTS branch?

So, again, there's simply nothing to discuss. I'm not big into how D team internals work, so how can I know what they want/need.

>

In other words: This is really close to happening is my impression. Why wouldn't you want to be one of the people helping to bring it over the goal line re. DLF buy-in so you actually get what you were after in the first place?

Contributing to any open-source project isn't a privilege. At least it shouldn't be, in my opinion. Especially, when everyone is saying how they "lack manpower". But when issues are brought up, they just resort to "nah" or "do it yourself". And even when you do it yourself, you end up in pages of useless arguing and very little productive being achieved. Or even your commits being reverted sigh

It's not that I expect D team to go and magically fix all my issues, and I never implied that. I'm jsut a language user crying for help coming up with a proposal to improve the language. I don't have expertise to be a language developer. And I sure don't expect blatant disagreeing and responsibility dodging from the D team. What I expect is:

  1. Understanding the problem
  2. Proposing a possible solution with a list of requirments
  3. Analyzing possible pitfalls to discuss

Only then a meeting is necessary. Those 3 steps can easily be discussed in a forum post without wasting everyone's time with pointless banter. I outlined the preconditions for (actually any) meeting:

>

I am willing to come to the meeting, fine, but only after some common ground is found on
topics of:

Needing LTS in the first place
Requirments and prerequisites for such an event
Your (D team's) proposition on how such thing could be achieved, and what resources are necessary for it

Otherwise (I'm probably repeating myself too much) there's simply nothing to talk about. It will be a stupid, pointless, phylosophical debate with nothing productive being achieved.

You can read this as: I'm a user that is willing to contribute, but I'm not going to spend my time begging and arguing, because there are other languages. I already spent enough time trying to do good things for D, and there is a decent chunk of sunk cost fallacy, but this can't go on forever. What angries me the most is how everyone is blatantly ignorant about users that they lose. For the love of everything that's holy, I already started my most recent project in C++, because it's just easier, despite everything bad about the language.

Take this with a little grain of salt, because I already stopped beginning projects in D. LTS isn't even the only problem with the language. It's one of the many that make D actually unusable in modern day programming. Unfortunately, none of them are being addressed.

P.S. I still don't understand why D team expects people to spend hours and days to get very little done in regards of productivity. Despite how many people have left because of those reasons. I don't understand why D treats 3rd party developers as morons/idiots/non-importnat people (please select the correct one), and why they still make no effort to support said 3rd party. Modern day programming is impossible without third-party. Because people would rather deal with C++ that has everything, than enjoy D that has nothing. (and it's not like D is really an enjoyable language to begin with)

June 11, 2023

On Sunday, 11 June 2023 at 22:25:48 UTC, GrimMaple wrote:

>

From my limited perspective, GDC is awful and is not good for production. Then again, it's not like any other D compiler is "good enough", maybe LDC is. But anyway, in practice, GDC is a rare beast and most people use DMD/LDC.

I don't understand why you say GDC is awful, it's simply D GCC frontend and behaves as one would expect from GCC.

GDC (like all GCC frontends) also has a great professional manual where it explains everything there is to know about the compiler, far superior to any other D compiler where the documentation I do not consider excellent.

What are your problems with GDC?

>

But this wasn't suggested by anyone from the D team.

It's literally on the dlang download web page, https://dlang.org/download.html.
I would say that it is certainly to be considered among the officially recommended compilers

>

P.S. I still don't understand why D team expects people to spend hours and days to get very little done in regards of productivity. Despite how many people have left because of those reasons.

I doubt the D team expects anything from people

June 11, 2023
On Friday, 9 June 2023 at 07:56:00 UTC, Walter Bright wrote:
> Thanks for spending the time to post this. We're going to take it to heart.

Don Clugston also strongly advocated for an LTS:
https://forum.dlang.org/post/mdjhbyvgxrjmbgzwirja@forum.dlang.org
June 12, 2023

On Sunday, 11 June 2023 at 23:20:31 UTC, mate wrote:

>

On Friday, 9 June 2023 at 07:56:00 UTC, Walter Bright wrote:

>

Thanks for spending the time to post this. We're going to take it to heart.

Don Clugston also strongly advocated for an LTS:
https://forum.dlang.org/post/mdjhbyvgxrjmbgzwirja@forum.dlang.org

The situation at Weka is very similar.

Trying to help the discussion a little bit.
I think there is some miscommunication because different people in this thread have different ideas of what "LTS" means/should be. Please define what you mean with "LTS"

What I think would help me (Weka) is having a stable language, not necessarily a stable compiler. Adding new features to the compiler can be very useful, but if every new compiler introduces language changes, then that becomes an issue.

With language changes I consider:

  • introducing a new deprecation/warning/error
  • removing keywords
  • changing meaning / behavior of something (incl standard library)
  • adding deprecation/warning/error for something that invokes defined but undesired behavior.
  • change of data layout. (although this is not defined by the language, users depend on this implementation detail because D is systems programming after all)
  • ...

Not:

  • adding deprecation/warning/error for something that clearly invokes undefined behavior (as noted by the spec)
  • adding a new feature (for example -i flag)
  • adding a new trait
  • ...

The current problem is that every compiler version introduces some language change. Even point-releases do that! (https://dlang.org/changelog/2.103.1.html#dmd.deprecate-pound-in-token-string)
So we technically have many different D language versions out there. The language changes are often in the "Compiler changes" category. But those are not compiler changes, they are language changes.

cheers,
Johan

June 12, 2023

On Sunday, 11 June 2023 at 23:20:31 UTC, mate wrote:

>

On Friday, 9 June 2023 at 07:56:00 UTC, Walter Bright wrote:

>

Thanks for spending the time to post this. We're going to take it to heart.

Don Clugston also strongly advocated for an LTS:
https://forum.dlang.org/post/mdjhbyvgxrjmbgzwirja@forum.dlang.org

I am referencing Mike Parkers' comment found inside the above link...
https://forum.dlang.org/post/zycmjfzasjmmswtbntim@forum.dlang.org

This is a great example of what I would like to see moving forward.

Imagine being able to create a new project and specifying the release you would like to use. If you don't have it, it will install it for you.

For example, when you dub init it could also ask the question :- "Which D release would you like? D23" etc.

In most cases, users/developers are likely to choose the current "milestone" release. However, the previous milestones can also be available. For sake of simplicity and point, lets assume the current milestone release is D23. Of course, specific releases can still be used (ie 2.104.0)

Of course, milestone releases can have patches - but must not break things! Ie D23.1 or D23.2, etc.

Imagine the next milestone, D25, being available months and months ahead of time as a pre-release (ie D25-Prerelease0.1, etc) allowing the maintainers to test/prepare their libraries.

Imagine if D encouraged a rule for libraries to follow to specific versioning patterns. For example:- {release.major.minor.etc} - Imagine a library having releases such as 23.4.2.10 or 25.1.2.0.

This tells us that D23 is available. I have increased confidence I can download this and "works" inside my D23 project. There is also a D25 version, the not-yet-released milestone. I now have confidence this library is very active into the next milestone release.

DUB could also be more intelligent when you dub add a dependency and, perhaps, handle validation (or test) upgrading to the next milestone.

"There is no release for D23. Suggestions...
D25 (25.1.2.0),
D21 (21.4.6.1)"

etc.

Obviously the regular releases can continue...
2.104.0
2.103.0
2.102.0
etc

These all get factored into the next milstone. Imagine a page for the next upcomming milestone to contain all of the new/updated features -- all on one page.

Yes, I am likely getting carried away with this. I understand that some of my points require some (big) changes in various areas including DUB - but I am just trying to demonstrate, and hopefully well, the many advantages to a LTS system/structure.

Until then, we have regular monthly (or every other month) releases. Could the next release break my application? What about LibraryX or LibraryY I am using? etc.

Thanks.

June 12, 2023

On Monday, 12 June 2023 at 11:01:35 UTC, Johan wrote:

>

Trying to help the discussion a little bit.
I think there is some miscommunication because different people in this thread have different ideas of what "LTS" means/should be. Please define what you mean with "LTS"

I sort of agree with this, but the goals are not exclusive. I don't see anyone disagreeing with the statement that the number of compilers currently in use makes it hard to share code with others (whether for money or otherwise). That can be fixed in less than a minute by labeling certain releases "LTS".

If someone wants to undertake a time-intensive effort to go beyond that, fine. It's not needed to improve the current situation though. We already have many compilers in the wild that aren't receiving updates. There's no reason to make this extra work a prerequisite to reducing the number of compilers you have to support in order to share your code with others.