D has become unbearable and it needs to stop (page 3)

Settings

Help

Index » General » D has become unbearable and it needs to stop (page 3)

June 08, 2023

Re: D has become unbearable and it needs to stop

Posted by Mike Parker
in reply to GrimMaple

Permalink

Mike Parker

Posted in reply to GrimMaple

Permalink

On Thursday, 8 June 2023 at 14:56:21 UTC, GrimMaple wrote:

The truth is, I've been nagging about LTS branches, and I've been nagging directly to Mike about it, and it went nowhere.
Per "core team doesn't care", when was the last time they had any meaningful meeting with said third party? When did they ask 3rd party developers directly about what they want or what they need? When did core team asked about "is it okay to deprecate this"?

At the end of every monthly meeting summary I post an open invitation for anyone who wants to bring something to us to discuss. I've been doing that for a while now. If you want to make the case for an LTS, that's the place to do it. Anytime you want to bring anything to the team, just email me and I'll bring you in.

June 08, 2023

Re: D has become unbearable and it needs to stop

Posted by GrimMaple
in reply to Mike Parker

Permalink

GrimMaple

Posted in reply to Mike Parker

Permalink

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

As far as I appreciate your efforts, becoming a language developer was never my intention. Especially, for free. I have other things to write (in D, mind you), and I'm only willing to help as much as I can -- I steadily file bug reports every time I encounter something; I'm keeping some code up to date; I contribute to other D libraries that I can contribute to. All I'm saying is, any further coding in D is going to be impossible if no effort is brought into stabilizing the language.

June 08, 2023

Re: D has become unbearable and it needs to stop

Posted by Mike Parker
in reply to GrimMaple

Permalink

Mike Parker

Posted in reply to GrimMaple

Permalink

On Thursday, 8 June 2023 at 15:29:08 UTC, GrimMaple wrote:

I'm not saying you should become a language developer. I'm saying if you have a strong case for an LTS release, bring it. I'm sure it's come up before, but no one has ever pushed it in a meeting that I can recall. I can't speak for everyone, but I wouldn't mind seeing it. I just know that there's a mountain of other work that we're putting a priority on right now, and until someone pushes it, I doubt anyone's going to pick it up.

June 08, 2023

Re: D has become unbearable and it needs to stop

Posted by IGotD-
in reply to GrimMaple

Permalink

IGotD-

Posted in reply to GrimMaple

Permalink

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

I wish I was exaggerating, but every new DMD version breaks some of my code, to a smaller or bigger extent. It can be either my own code, or dependency code, but I started drowning in deprecation messages or outright breakage. It's nearly impossible to develop any reasonable 3rdparty in those conditions. I'm tired of fixing things that weren't broken. And I can't even imagine having to support multiple branches of code because of those deprecations. But I probably should, as, periodically, I get issues that dlangui can't compile with some outdated dmd version. It's just insane!

Recently, some of the changes resulted in direct API changes. This is unacceptable, as it, basically, forces people to update major versions and split the codebase between "before" and "after". Also forcing them to support two version of the same thing.

Thank you for sharing this and this is a valid concern indeed. Unfortunately D is run as a hobbyist project for langauage geeks with little concern for the professional environment. It is nothing wrong with language geeks having a project but it doesn't mix well with projects that require stable language+stdlib. I repeat over and over again, we need to start with D3 so that language geeks can have a platform without interfering with D2. D2 should be put in maintenance mode now and the language should be considered to be finished.

June 08, 2023

Re: D has become unbearable and it needs to stop

Posted by Steven Schveighoffer
in reply to Adam D Ruppe

Permalink

Steven Schveighoffer

Posted in reply to Adam D Ruppe

Permalink

On 6/8/23 11:21 AM, Adam D Ruppe wrote:

On Thursday, 8 June 2023 at 15:00:04 UTC, Steven Schveighoffer wrote:

In this case, __traits(getAttributes) was wrong, so a bug is being fixed. How do we fix bugs like this without using deprecations and eventual removal?

The problem is that there is no easy migration path for the cases where it actually did work just fine. The update required an extra static if branch added to each use for a generic loop.

You mean, it happened to work because of the ordering of the overloads? This is the nature of things that do something incorrect in the face of ambiguity.

This very much reminds me of the cycle detection problems I fixed. Cycles wouldn't get detected, because the algorithm was flawed. Fix the algorithm, and now "working" code breaks because there actually is a cycle. What do we do about it?

The answer at the time was to introduce a ridiculous deprecation system, where I implemented both the correct algorithm and the incorrect algorithm, and ran both. Then if they disagreed, still allow it and print a deprecation message.

In my estimation that is what is happening here -- you are relying on a faulty implementation, and that reliance is being deprecated.

Moreover, a loop over overloads still required an additional getOverload since the deprecation message triggers in cases when it shouldn't have!

foreach(idx, overload; AliasSeq!(__traits(getOverloads, Module, memberName))) static if(.isScriptable!
(__traits(getAttributes, __traits(getOverloads, Module, memberName)[idx]))()) { // lol i have to do the second getOverload to stop the compiler from deprecating

That seems like a bug in the deprecation. If you have the overload, you shouldn't need a second getOverload.

And... bug just filed a few days ago.

https://issues.dlang.org/show_bug.cgi?id=23966

-Steve

June 08, 2023

Re: D has become unbearable and it needs to stop

Posted by bachmeier
in reply to Steven Schveighoffer

Permalink

bachmeier

Posted in reply to Steven Schveighoffer

Permalink

On Thursday, 8 June 2023 at 15:11:50 UTC, Steven Schveighoffer wrote:

An LTS branch needs at least one dedicated person to keep it up to date with any bug fixes that happen in the main line. This is not a trivial task.

But that's not the purpose of an LTS release. You do it so you can share your code with others without having to support every compiler release for the last several years. A good example for another language is what R does for Ubuntu releases:

https://cran.r-project.org/bin/linux/ubuntu/

Some background: It's a nightmare trying to install R packages on Linux these days because that's traditionally been done from source. One of the prolific package writers adds insane numbers of dependencies like he's writing Javascript, and many of those dependencies require compilation of C++, which has miserable compile times. It's not unusual to spend more than an hour installing a single package because you need a single function it provides. Since it got to the point of impractical to use R on Linux, someone created the c2d4u repo. As it says on the linked page: "The ‘c2d4u’ repository is only available for LTS releases." It doesn't matter which release is labeled LTS, what matters is that Ubuntu 20.04 and 22.04 are the only things they have to support - but they couldn't do that with Ubuntu labeling one of their releases every two years as LTS.

That's not to say that big fixes couldn't be backported if they were valuable. Just that it's orthogonal to LTS.

June 08, 2023

Re: D has become unbearable and it needs to stop

Posted by Adam D Ruppe
in reply to Steven Schveighoffer

Permalink

Adam D Ruppe

Posted in reply to Steven Schveighoffer

Permalink

On Thursday, 8 June 2023 at 15:50:22 UTC, Steven Schveighoffer wrote:
> You mean, it happened to work because of the ordering of the overloads?

Yes, attaching an attribute to the first overload worked well for a lot of cases and could have been specified to work. Or maximally, overload sets could be a well-defined concept in D and the symbol refers to them and then UDAs either don't attach to them or... something. Or, minimally, going from overload set to specific overload could have been made trivial and generic with other symbols that are not overload sets, so you can migrate by calling that instead of doing an extra branch externally.

> This is the nature of things that do something incorrect in the face of ambiguity.

Technically, the spec is still ambiguous:

https://dlang.org/spec/traits.html#getAttributes

"Takes one argument, a symbol. Returns a sequence of all attached user-defined attributes. If no UDAs exist it will return an empty sequence "

It doesn't say anything about special treatment of overload sets, so it doing the same thing as the rest of the language - using the first one - is no more or less wrong than anything else.

In fact, it giving a deprecation is probably a violation of the spec...

These "bugs" ought to be defined in terms of the spec, and spec changes ought to be reviewed before merged.

> That seems like a bug in the deprecation. If you have the overload, you shouldn't need a second getOverload.

Yes, indeed, the implementation of the deprecation is obviously broken.

Yet it shipped anyway.

June 08, 2023

Re: D has become unbearable and it needs to stop

Posted by GrimMaple
in reply to IGotD-

Permalink

GrimMaple

Posted in reply to IGotD-

Permalink

On Thursday, 8 June 2023 at 15:48:26 UTC, IGotD- wrote:

Thank you for understanding my issues. I also think D2 is good enough to be considered finished. Personally, I would've branched it at around 2.100. That's before ImportC.

I too get this feeling that D is a hobbyist project, mostly directed towards language creators, not software engineers. Which is why most of people I know avoid D as if it was a plague. And which is why there isn't much 3rdparty on dub to begin with.

June 08, 2023

Re: D has become unbearable and it needs to stop

Posted by Ernesto Castellotti
in reply to IGotD-

Permalink

Ernesto Castellotti

Posted in reply to IGotD-

Permalink

On Thursday, 8 June 2023 at 15:48:26 UTC, IGotD- wrote:

I repeat over and over again, we need to start
with D3

I agree, but I doubt the dlang foundation would agree either

so that language geeks can have a platform without interfering with D2. D2 should be put in maintenance mode now and the language should be considered to be finished.

Cool, but after that who will continue to maintain D2?

June 08, 2023

Re: D has become unbearable and it needs to stop

Posted by Johan
in reply to FeepingCreature

Permalink

Johan

Posted in reply to FeepingCreature

Permalink

On Thursday, 8 June 2023 at 13:54:53 UTC, FeepingCreature wrote:

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

I usually try to stay more silent (on the form at least), but I think I reached my boiling point. I've been a (self employed) full time D developer for almost 2 years now, developing quite a large codebase of personal closed source projects, as well as adopting some 3rdparty code like dlangui. And my life has become particularly miserable in the last half a year or so.

I wish I was exaggerating, but every new DMD version breaks some of my code, to a smaller or bigger extent.

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.

Can 100% confirm (Weka), and I share the frustration. Breakage happens upon every release, with significant effort involved to find and fix the breakage (i.e. you hire a compiler dev for it = me).
Breakage is due to:

Intentional change of behaviour, sometimes without clear solution path or with buggy solutions. https://issues.dlang.org/show_bug.cgi?id=23966 and 23977 for recent examples.
New bugs due to some improvement or new functionality.

I'm not sure, but I think this is mostly due to a severe lack of rigorous test cases, and unstructured compiler implementation (no splitting of certain analyses into well-defined functions (copying around of complex analysis) and too many special cases all around the semantic analysis for example). A change made in part X, has high likelihood to change behaviour of a seemingly unrelated part Y, and the lack of test cases means it will go undetected.

The breakneck pace of releases means that the releases themselves do not get sufficient community testing (who tests betas?? lol, I'm still working on fixing the code for the release from last year). So every release is maintaining the level of immaturity (note: .0 releases I don't even consider, .1 or .2 (what LDC uses) is slightly better).

-Johan

Top | Forum index | About this forum

Forums