Why is D's GC slower than GO's?

[Ola Fosheim Grøstad]

On Sunday, 30 October 2022 at 07:16:27 UTC, Walter Bright wrote:
> On 10/29/2022 11:41 PM, Paulo Pinto wrote:
>> No one has bothered to endure the work and the voting process 
>> to make it part of ISO, including Microsoft that published it 
>> via ECMA.
>> 
>> As for why no other has adopted it, it really only makes sense 
>> for bytecode based stacks, and there is no competition to CLR 
>> for low-level languages.
>
> Not a good sign for D needing to adopt managed pointers.

There is no demand for having a GC in c++ either. The GC support 
in std is being removed in C++23, and very few projects use the 
boehm collector (which is very close to the D one).

Cabon will also not have a GC (maybe ref count optimizations). 
Likewise Rust.

So there is no indication that there is a significant demand for 
GC among system level programmers/corporations that depend on 
system level code bases. Not even as an option.

And even the Microsoft example is basically about interop, not 
system level programming.

But you are right that it is attractive for anything that happens 
at compile time. However, if you want GC to be attractive at 
runtime then you need a new strategy at the language design level 
where threads dont have a negative impact on each other. Even 
then it will be an uphill battle as will need to create a demand 
for it (you would need to change existing practice).

(Swift and Go are usually not considered system level.)