We are forking D (page 3)

On Tuesday, 2 January 2024 at 17:55:56 UTC, GrimMaple wrote:

Hello everyone!

On this page it's mentioned:

D's current dictatorship model goes contrary to those lessons. Whether benevolent or not, a dictator is still a single point of failure and a bottleneck on the process. We need to correct this to finally allow D to thrive.

I think it's easy to fall into the trap of replacing one "dictator" with another. For example, the roadmap on that page lists language features which will be added or removed. But, who decided on this? The community? Or just another person who declared themselves to be the new ruler?

I'll be really curious to see how the new leadership handles themselves when tough calls have to be made.

Wishing you all the best.

January 03

Re: We are forking D

Posted by Martyn
in reply to GrimMaple

Permalink

Martyn

Posted in reply to GrimMaple

Permalink

On Tuesday, 2 January 2024 at 17:55:56 UTC, GrimMaple wrote:

Hello everyone!

Growing greatly dissatisfied with how things are in the D Programming Language, we decided it is time to fork it.
We want to change the way decisions are made, giving both more freedom to change, and more speed to decision making. We want the process of contribution to be as open-ended as possible, and not having unnecessary blockage to contributions. We also want the language to allow for faster software development. The way this is going to be achieved is still not finalized, but that is the goal.
One of the ways to achive our goal is to have core focuses of the language. Such focuses are:

Embracing the GC and improving upon it, disregarding betterC and nogc in the process
Concentrating on the code being @safe by default
Revizing & rewriting the standard library, making std.v2
Improving druntime and porting it to other platforms, like wasm
Encouraging writing code in D, not sticking up with C
Improving toolchain

The following stuff will be forked:

dmd
ldc
phobos
druntime

As hard as it is to say this, unfortunate code breaking changese are going to be made. But only if they help achieve the goals listed above.

The forking process is still in progress, and there isn't much done per se. We are discussing the future of the fork and what we want from it, it might be a little crazy at first. But if you wish to help out, bring your changes in, or just look around, please join our Discord server to discuss: https://discord.gg/tfT9MjA69u . Temporary website: https://dpldocs.info/opend/contribute.html

Thank you, and good luck.

I was expecting a post like this from one of (about) 5 regulars in this forum.

The only area I personally would disagree on is:-
Embracing the GC and improving upon it, disregarding betterC and nogc in the process

I think GC should be optional or, atleast, have some kind of Allocator feature so we can have control if needed.

D allows you to code whatever way you like, or a combination of them... why not provide this power when it comes to memory?

(To those it concerns -- I am not interested turning this into another side debate of GC or other areas, like the other post before xmas. I am probably the minority with this mindest. If I am, then good luck - but I don't think this will serve my purposes if you go this route)

Forums