On Saturday, 29 October 2022 at 04:46:21 UTC, Walter Bright wrote:
> If there was a way around these two issues, we would have found it by now.

It's very easy to "work around these two issues" but you cannot see it because of DOS's NEAR and FAR pointers. If that sounds totally absurd, it's because it is.

> 1. It enables a killer feature - CTFE that can allocate memory. C++ doesn't do that. Zig doesn't do that.
>

And Nim does that easily too without butchering the type system. There simply is no reason to conflate managed with unmanaged pointers.

On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:
> ..
> Is D really that bad?

No. If you use the version of D that I use, that has BOTH private to the class AND private to the module, then .. D is not that bad ;-)

On Saturday, 29 October 2022 at 01:59:13 UTC, Walter Bright wrote:
> On 10/28/2022 2:51 AM, Imperatorn wrote:
>> And still, people still think Zig is better for some reason.
>
> Zig has very good marketing.
>
> The best thing we can do, is simply write articles about the programs we write in D.
>
> Submit presentation proposals at conferences other than DConf help a *lot*. And the people who have presented at DConf in the past already have presentations ready to go. Please just submit them!
>
> Even for CPPCON. Submit a proposal about interfacing D to C++.
>
> Or do one of those youtube videos showing yourself developing a D program.

True, I never understand how they do it though. D *is* superior.

Maybe I will do some videos on D development next month actually.

On Saturday, 29 October 2022 at 02:02:33 UTC, Walter Bright wrote:
> On 10/28/2022 3:20 AM, IGotD- wrote:
>> [...]
>
> You can fork it if you like. Feel free!
>
> Meanwhile, last week I spent fixing some gaps in the XMM semantics (relational operators are now supported).
>
> Before that, I went through every DIP1000 bugzilla issue, and submitted PRs for the problems.
>
> Before that, I went through (again) the list of outstanding issues with ImportC and fixed the top problems.

Thank you!

On Saturday, 29 October 2022 at 04:46:21 UTC, Walter Bright wrote:
> With such heavy GC allocation, a reasonable tradeoff is to insert "write gates" on every write through a pointer. This informs the GC that the allocation is "dirty" and so can be moved to more recently used places. These write gates slow the code down, but they speed up the GC even more, and so they are worth while.

If by "write gates" You mean additional code generated for every write, then you don't need it, You can use GetWriteWatch (on windows) or mprotect and signal handling (on linux, and probably other posix compliant OSes) to get list of modified pages on GC heap.

> The GO GC can also take advantage of always knowing exactly where all the GC pointers are, because there are only GC pointers. This enables a moving GC, which "compacts" fragmented memory.

You don't need to know where **all** GC pointers are (in the sense that you know if something is pointer or not), if You don't know if something is pointer or not (because for example it's part of union) just pin pointed object to prevent it from being moved.

> When GC is optional, or used rather rarely, as in D, the write gate technique is a net loser. The GC is sped up at the cost of slowing everything else down. And since there are all kinds of pointers in D, one no longer can use a moving GC allocator, because it cannot know exactly where 100% of the GC pointers are.
>
> If there was a way around these two issues, we would have found it by now. But by adding write gates, and making GC pointers the only pointers, D won't be systems programming language anymore.

So since there is no need to add write gates and making GC pointers the only pointers, it should be possible.

On Saturday, 29 October 2022 at 06:28:02 UTC, Araq wrote:
> On Saturday, 29 October 2022 at 04:46:21 UTC, Walter Bright wrote:
>> If there was a way around these two issues, we would have found it by now.
>
> It's very easy to "work around these two issues" but you cannot see it because of DOS's NEAR and FAR pointers. If that sounds totally absurd, it's because it is.
>
>> 1. It enables a killer feature - CTFE that can allocate memory. C++ doesn't do that. Zig doesn't do that.
>>
>
> And Nim does that easily too without butchering the type system. There simply is no reason to conflate managed with unmanaged pointers.

I agree Nim does some things a lot better, I do.
On the other hand D has a better community than Nim.

In the end, everything is a trade off.

I have long argued that we should support it as an opt-in flag.

Because right now, if someone wants to experiment with these more powerful GC designs that can't. So there is no evidence that they couldn't benefit D.

At the very least it could generate some very interesting research papers if we find the right person to try it out. Especially for GC heavy applications like web services (vibe.d).

Ok, I'll byte. Present an actual design that will work with D.

On 10/29/2022 1:12 AM, Piotr Duda wrote:
> If by "write gates" You mean additional code generated for every write, then you don't need it, You can use GetWriteWatch (on windows) or mprotect and signal handling (on linux, and probably other posix compliant OSes) to get list of modified pages on GC heap.

I once tried an implementation that would set the virtual page to read-only, and then capture the seg fault when it was written to. This turned out to be quite a bit slower.

Hey, I have no problem with being wrong. I welcome a design for a better GC.

Go ahead, make my day :-)