Perhaps, we should also be considerate of author D. perhaps, what we discussed, D author, has been discussed for a long time. We can't check all quotations of D author. Maybe he just doesn't want to spend time explaining.
I used to remember that D author told us just to do what we were interested in. Maybe,let's just do it.
Those who tells us to do DC++ alone just want us to leave. They want to make d DC#. No, we can't let them satisfy. We'll just improve it on d.
D author has been focusing on action rather than management. OK, let's do it ourselves.
We can start with the details of where we feel uncomfortable.
If we don't act, and wait for d author to lead us or give us directions. Maybe it will be a long time.
However, we still need to use d. Let's start with small details one by one. Don't wait for them. Let's just do it ourselves.

On Wednesday, 19 May 2021 at 12:30:18 UTC, zjh wrote:

It was already that! It changed horses in midstream, trying to become DC++.

There are various problems with DMD and other software, those are all solvable or tolerable.
The big technical problem is that the D programming language tries to offer good support
for different kinds of memory management. This is a hell of a task, especially in a situation of limited resourses (manpower etc).
As far as I can tell, the plan (implicitly) is (was?) this: implement some kind of limited-borrow-checker-kind-of-thing (dip1000), implement refcounting of pointers and use dip1000 to optimize the refcounting. And then presumably abandon the GC.
For now it doesn't seem to work, probably because it's very difficult to do all that. Meanwhile, GC does work, even though it's not a great one.

What's the point of talking about small details when there is an elephant in the room.

On Wednesday, 19 May 2021 at 12:30:18 UTC, zjh wrote:

Yes, that is also what I fear when I see new big features being added.

I think I can fix most of the small details that bugs me the most, myself, but not the larger issues such as memory management. At some point it becomes easier to switch focus to something like Feeble's CX language or design your own from scratch. So, if CX is being developed into something interesting and D does not get proper memory management, that is a more likely option I think.

Anyway, as I pointed out, forking DMD is not so difficult, but the main issue with it is that the DMD source code should be split into smaller files. Then one can "overwrite" files that has not changed when DMD is updated with new versions, and manually modify (or patch up) the DMD files that has changed. Maybe it is easy to do this with the large source files DMD has for someone that does this all the time, but I have no intent of being an expert on merging... (rebasing). So at it stands, DMD needs restructuring before I want to do big changes to it.

Well, I don't know what to do.
No small change, no big change.
Let's stand still.

my c++ source file is also small.
I like small files too.
indeed,I feel D author is using d like C,and not much like C++'s OOP.

On Wednesday, 19 May 2021 at 13:25:20 UTC, zjh wrote:

If this was my process then I would have created an opn working group forum for memory management, defined what is off limits (core requirements) and let people discuss. They apparently are going for a closed group. The problem with this is that you can get en echo chamber where the wrong solution is picked... Meaning if you select people that already agree with you, you might end up with more of the wrong questions and then you also get the wrong answers...

But, we'll see.

I cannot tell you what to do, but I am starting to look at combining Swift and C++.

On Thursday, 13 May 2021 at 20:57:13 UTC, dogman wrote:

D is already largely fit for industry. In my niche, there is only C++ competitors, and exactly zero Rust/Go/Zig competitors. D is a practical language, not the "earn the maximum of points of HN"-type language.

On Wednesday, 19 May 2021 at 16:16:39 UTC, Guillaume Piolat wrote:

Hackernews is one of the only places you can actually find people who've even heard of D.

D is already in a good state but there are still things that leave a lot to be desired, and people on hackernews may enjoy fashion but they usually aren't dumb so I wouldn't be too dismissive.

I believe something like this will shut up most of the criticisms on planning/roadmap etc:

https://isocpp.org/files/img/wg21-timeline-2020-02.png

It doesn't have to be very detailed, just one page summary very easy to digest. If dates are not known, just use "TBD".

Most importantly, people wants to know what is happening and what will happen in future for D-language and who are the primary owners/leaders of that work at birds eye view. A simple table with key information may suffice.

Most definitely I don't want to see buckets and buckets of of text like these: https://wiki.dlang.org/Vision_statements

Core team and current leadership may know whats happening nowadays, but for external visitors, its never clear from the dlang website.

my 2c.

On Wednesday, 19 May 2021 at 17:09:25 UTC, sai wrote:

Thank you! This is exactly what I'm looking for (personally). Well said.