Re: SerpentOS departs from Dlang
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.
Re: SerpentOS departs from Dlang
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).
Re: SerpentOS departs from Dlang
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.
Re: SerpentOS departs from Dlang
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?
Re: SerpentOS departs from Dlang
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.
Re: SerpentOS departs from Dlang
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.
Re: SerpentOS departs from Dlang
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.
