Jump to page: 1 2
Thread overview
SerpentOS departs from Dlang
Sep 15, 2023
M.M.
Sep 15, 2023
ryuukk_
Sep 16, 2023
Adam Wilson
Sep 16, 2023
sighoya
Sep 16, 2023
Adam Wilson
Sep 17, 2023
ryuukk_
Sep 16, 2023
Imperatorn
Sep 20, 2023
Greggor
September 15, 2023

In February there were some exciting news on the usage of dlang within serpent-os linux distribution, quite a large open source project of Ikey Doherty and the team around him.

Unfortunately, the project decided to leave dlang behind, and to embrace golang and rust instead... in part due to some hiccups in dlang and due to contributors pushing for more mainstream languages:

https://serpentos.com/blog/2023/09/06/oxidised-moss/

Pity that it did not succeed. It would be a great showcase for the marvelous dlang.

September 15, 2023

On Friday, 15 September 2023 at 17:39:41 UTC, M.M. wrote:

>

In February there were some exciting news on the usage of dlang within serpent-os linux distribution, quite a large open source project of Ikey Doherty and the team around him.

Unfortunately, the project decided to leave dlang behind, and to embrace golang and rust instead... in part due to some hiccups in dlang and due to contributors pushing for more mainstream languages:

https://serpentos.com/blog/2023/09/06/oxidised-moss/

Pity that it did not succeed. It would be a great showcase for the marvelous dlang.

That's unfortunate..

Ikey seems to still want to use D, so the main driving factor is the contributors, i wonder what are the exact reasons, pseudo memory safety can't be the only reason

To be honest, I wouldn't blame contributors for looking at more mainstream languages, who still want to do their switch cases this way:

switch (it)
{
    case MySuperLongEnum.MySuperLongValueA:
       result = do_something_a();
    break;
    case MySuperLongEnum.MySuperLongValueB:
       result = do_something_b();
    break;
    case MySuperLongEnum.MySuperLongValueC:
       result = do_something_c();
    break;
}

When other languages have it cleaner:

result = switch (it)
{
    .MySuperLongValueA: do_something_a();
    .MySuperLongValueB: do_something_b();
    .MySuperLongValueC: do_something_c();
}

Improving ergonomics won't necessarily attract people, probably not, but i'm pretty sure that'll make contributors of existing projects not request to change language because the ergonomics are so poor

Even C# understand that and made the appropriate changes across their language and even improve their compiler to avoid the urge to switch to Go (NativeAOT), even Java made appropriate language changes in hope to stay relevant, why only D should be frozen? Acting like the world depend on D

D has many benefits, but some areas need lot of love, this reminds me of this dude in an online chat, he said the reason why he stick to Rust was because of Rust's enum.. not because of memory safety

Hopefully more wake up calls like this one will resonate with the D foundation

September 16, 2023

On Friday, 15 September 2023 at 21:49:17 UTC, ryuukk_ wrote:

>

Ikey seems to still want to use D, so the main driving factor is the contributors, i wonder what are the exact reasons, pseudo memory safety can't be the only reason

I would guess that the following is the bigger problem:

"we don't quite have the resources to also be an upstream for the numerous D packages we'd need to create and maintain to get our works over the finish line."

This has long been a chicken-egg problem for D. We need more packages to attract more users, but we need more users building packages before we can attract more users.

DIP1000 is also a bit of marketing problem. We kinda-sorta promise that someday you'll be able to build memory safe programs without a GC. We need to either push through and get it done, or admit we're not actually going to get there and cut it.

I know there are ref-counted languages so theoretically it should be workable, but the in a language as complex as D there may be dragons on the edges. In any case, we should not be marketing something we can't actually do.

September 16, 2023
On 16/09/2023 9:02 PM, Adam Wilson wrote:
> I know there are ref-counted languages so theoretically it should be workable, but the in a language as complex as D there may be dragons on the edges.

The approach that I think will work well for us is to support reference counting on structs & classes, and make them not adhere to DIP1000.

Then you borrow memory from them, and DIP1000 takes over.

This minimizes the surface area of the language that needs to understand reference counting and life time handling. So our one dimensional approach with DIP1000, will absolutely shine.

I will be doing the DIP for RC due to its cost of it and the fact that modern backends do understand it and can make it cheaper.
September 16, 2023

On Friday, 15 September 2023 at 21:49:17 UTC, ryuukk_ wrote:

>

On Friday, 15 September 2023 at 17:39:41 UTC, M.M. wrote:

>

[...]

That's unfortunate..

Ikey seems to still want to use D, so the main driving factor is the contributors, i wonder what are the exact reasons, pseudo memory safety can't be the only reason

[...]

To be fair though, you could just have a map between string and func like
result = func[myEnumName] or use metaprogramming.

But yes, D would benefit from having real pattern matching.

September 16, 2023
On Saturday, 16 September 2023 at 10:22:31 UTC, Richard (Rikki) Andrew Cattermole
wrote:
>
> The approach that I think will work well for us is to support reference counting on structs & classes, and make them not adhere to DIP1000.

Does that mean you are against dip1000 or do you want both?

> I will be doing the DIP for RC due to its cost of it and the fact that modern backends do understand it and can make it cheaper.

Will it be automated reference counting with a special type of GC doing the job or a local RC container?

September 17, 2023
On 17/09/2023 12:25 AM, sighoya wrote:
> On Saturday, 16 September 2023 at 10:22:31 UTC, Richard (Rikki) Andrew Cattermole
> wrote:
>>
>> The approach that I think will work well for us is to support reference counting on structs & classes, and make them not adhere to DIP1000.
> 
> Does that mean you are against dip1000 or do you want both?

Basically DIP1000 handles the final leg of lifetime management, rather than managing the actual ownership of memory. It comes into play after you borrow from a container.

>> I will be doing the DIP for RC due to its cost of it and the fact that modern backends do understand it and can make it cheaper.
> 
> Will it be automated reference counting with a special type of GC doing the job or a local RC container?

Its basically what we do now with copy constructors + destructors, but inside dedicated methods.

Although I do want a write barrier on each struct/class, to allow for cyclic handling especially for classes.

September 16, 2023
On Saturday, 16 September 2023 at 12:34:24 UTC, Richard (Rikki) Andrew Cattermole wrote:
> Although I do want a write barrier on each struct/class, to allow for cyclic handling especially for classes.

How dare you bring the High Heresy of write barriers into D! I thought that it was well understand that even mentioning Write Barriers is a mortal sin against the Church of @nogc.

Kidding aside. If you do this, you might as well turn them on everywhere. After that it's a easy stroll to a non-blocking moving GC, which would end most complaints about the GC (nobody complains about the .NET GC anymore).


September 17, 2023
On 17/09/2023 11:46 AM, Adam Wilson wrote:
> Kidding aside. If you do this, you might as well turn them on everywhere. After that it's a easy stroll to a non-blocking moving GC, which would end most complaints about the GC (nobody complains about the .NET GC anymore).

The scope of each doesn't match up, and you'd still need the RC specific write barriers.

So when I say write barrier what I mean is:

```d
class MyRoot : void {
	void opRCWriteBarrier(size_t fieldOffset, void* pointer) {
		myCyclicDetector.set(cast(void*)this, fieldOffset, pointer);
	}

	void opRCSub() {
		if (atomicOp!"-="(this.refCount, 1) > 0)
			myCyclicDetector.collect(cast(void*)this);
	}
}

class Child : MyRoot {
	Array!int array;

	void func() {
		array = new Array!int();
		// this.opRCWriteBarrier(array.offsetof, cast(void*)array);
	}
}
```

Only needs to support classes + structs (I think), so its surface area is pretty small.

Oh and Walter has approved anyone to experiment with write barriers ages ago, although nobody has.
September 17, 2023
On Sunday, 17 September 2023 at 00:55:22 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 17/09/2023 11:46 AM, Adam Wilson wrote:
>> Kidding aside. If you do this, you might as well turn them on everywhere. After that it's a easy stroll to a non-blocking moving GC, which would end most complaints about the GC (nobody complains about the .NET GC anymore).
>
> The scope of each doesn't match up, and you'd still need the RC specific write barriers.
>
> So when I say write barrier what I mean is:
>
> ```d
> class MyRoot : void {
> 	void opRCWriteBarrier(size_t fieldOffset, void* pointer) {
> 		myCyclicDetector.set(cast(void*)this, fieldOffset, pointer);
> 	}
>
> 	void opRCSub() {
> 		if (atomicOp!"-="(this.refCount, 1) > 0)
> 			myCyclicDetector.collect(cast(void*)this);
> 	}
> }
>
> class Child : MyRoot {
> 	Array!int array;
>
> 	void func() {
> 		array = new Array!int();
> 		// this.opRCWriteBarrier(array.offsetof, cast(void*)array);
> 	}
> }
> ```
>
> Only needs to support classes + structs (I think), so its surface area is pretty small.
>
> Oh and Walter has approved anyone to experiment with write barriers ages ago, although nobody has.

I hope we'll see tagged union + tuple come first before that mess you are describing, because to me this sound like a giant waste of effort, time and opportunity

You'll never attract more people if you focus on OOP / GC, that kind of code is repulsive to be honest

Tagged Union alone will help build libraries that doesn't require that OOP crap and help reduce the need of a GC significantly, more structs, less class, more values less heap allocated garbage for a collector to stop the world

D has ton of features that help avoid GC completely, let's focus on more of that

Atila, didn't you say "allocator good", so where are they? leadership is also frozen?
« First   ‹ Prev
1 2