On Saturday, 25 June 2022 at 13:14:46 UTC, Ola Fosheim Grøstad wrote:

All of the options you mentioned probably won't happen, especially the LLVM option is never going to happen.

On Saturday, 25 June 2022 at 08:08:46 UTC, zjh wrote:

Yes, I agree, but D has to be a language that C++ programmers want to use in their spare time, so it has to less complex with clean syntax and not try to become like C++. There is also no point in becoming a language like Rust.

You could also look at github, to see what kind of projects people make.

Btw here are the stats for number of created repositories on github in the past 6 months (roughly, github search is a bit inaccurate):

There is a big gap between popular languages and niche languages.

On Sunday, 26 June 2022 at 11:51:31 UTC, mee6 wrote:

I agree that the LLVM option isn't going to happen.

The most I would hope for is that Atila has enough interests in the actor model to push for destruction free GC and actor local GC as an option. If ~5 capable devs are interested then it could happen as an alternative runtime option.

(Ideally, an actor local GC should be compacting when memory pressure is high, but I doubt that will ever happen for D.)

On Sunday, 26 June 2022 at 11:58:31 UTC, Ola Fosheim Grøstad wrote:
so it has to less complex with

In D's what partion do you think can be simplified?
Language is borned to be complex, because you have a variety of needs to meet.
D language needs to raise '95%' to 100% one by one.
Then, as d users, we can proudly help d's promote in various fields!
What is needed is reasonable arrangement of time/manpower/money.
The most important things should be done one by one
Don't worry about the small number of users now. First meet the needs of existing users .
Stabilize the basic users!
First sort the 'todo priority', and there is no one so far.
I didn't see the D's task list.
We should make rational use of the power of the community.
It's too difficult to rely on just a few key people to compete with other lanuguage.

On Sunday, 26 June 2022 at 12:24:11 UTC, zjh wrote:

We should let d users actively participate in 'd'.
Explain 'DMD' and 'backends' in detail. 'D' needs to rely on the 'power' of the community.
Other languages also rely on it.
D official should put forward a list of important todos so that the community can actively participate!
Just like distributing tasks, you should first 'list tasks' instead of just 'writing code'.
D's improvement needs constantly promoted by D's users.
The same is true for other languages.
Therefore, should listen carefully to the needs of the 'users'!
The slogan can be simply 'serve for expert programmers'!
With experts to help you expand the lib base, won't ordinary users come?

On Sunday, 26 June 2022 at 12:24:11 UTC, zjh wrote:

Depends on what we mean with «complex». Simple languages can be powerful (Scheme/Prolog). Primitive languages can be complex to use (bad syntax, inconsistencies, special cases).

The easiest way to avoid being perceived as complex is to not deviate from other languages on basic stuff and have a high degree of consistency internally. The less additional things you have to remember, the less complex it will feel.

Right now the most important thing is to not add additional complexity and still solve remaining issues. Then one can take one step back later and do a syntax cleanup when all the semantics are right.

Yes, well, that is an issue. Not many people will volunteer to work on the DMD code base without a cleanup. And not many people will volunteer to work on SDC until it has reached a more mature stage as they don't know if it will reach completion…

It is a catch-22 situation that can only be fixed by the core team setting a new direction.

Yes. The problem is that you need a high level design that people believe in first. I don't believe in @live or DIP1000 or Rust-semantics.

I could believe in actor-local GC. I could believe in concurrent GC. I could believe in ARC.

But with no high level design decision by the core team, not many will be motivated to move as they would be alone and would not know if their efforts would be undermined by new language semantics coming out of nowhere.

So the «do it yourself» does not work in this case, it is a high risk to take.

It is lower risk to go create your own language.

On Sunday, 26 June 2022 at 12:35:51 UTC, zjh wrote:

Or ,D is for expert!

The direction of D is not obvious now, that is, the number of users is small. What D needs most is experts!
If the direction is not obvious, then we can just 'serve for the experts' !
Where experts go, where d!
At least, this is also a direction!
D needs experts to write the lib base, and also requires experts to improve DMD.
Therefore, D should introduce 'DMD' in detail .
Attract experts in different fields to improve 'DMD'!
Where experts go,Where d go! In this way, D has a direction .
If there are many experts in some field, naturally 'd' is good at that field, isn't it?

On Sunday, 26 June 2022 at 12:56:00 UTC, zjh wrote:

Yes, d needs to be organized!
At present, it is very important to make a to-do list!
We can solve the "small problems" first, and then the "big problems". In any case, we should list the problems first!
Simple problems are handed over to 'd' ordinary users, and to users of different levels according to the difficulty of the problem.
Also need a branch to 'radical' reconstruct dmd. Now, after finishing the features at hand , stop new features. solve the problems that 'users' are most dissatisfied with first!

On Sunday, 26 June 2022 at 13:09:04 UTC, zjh wrote:

'radical' reconstruct dmd is a must.
If experts can not implement features well, how can ordinary users contribute for dmd?

On Sunday, 26 June 2022 at 13:09:04 UTC, zjh wrote:

I think it is a good idea to focus on the "big issues" as those most likely are the ones that make people reduce their activity and use the language less.

Anyway, Mike Parker said he would publish a vision document soon, so we just have to wait and see what is possible and what is not (in the near future).