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

[Paulo Pinto]

On Sunday, 30 October 2022 at 07:52:09 UTC, Ola Fosheim Grøstad 
wrote:
> 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).

If you bothered to read the rational, the main reason are the 
companies that care about GC in C++, like Epic and Microsoft, 
didn't adopt the C++11  API.

Every, single AAA game studio using Unreal has demand for having 
GC in C++, just like every Windows application written in WPF.

So it is a pity that it is gone, but if the companies that care 
about don't want it, better clean up the standard.

Yet another good example how stuff gets into the standard, by 
having enough votes, but not from the companies that actually 
care about the feature in production code.

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

It remains to be seen if Carbon will ever happen

> 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).

Most of that demand comes from cargo cult against any kind of 
automatic memory management.

In some embedded circles, progress has stopped in C89, should we 
also measure computing world lack of progress by those folks?

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

Swift is definitly a system level, Apple is quite clear about it 
on documentation and WWDC keynotes, and on iOS 16 it already 
surpaced C++ usage.

It is one of the reasons why Apple has stop caring about C++ 
beyond C++17, and stepped away from clang contributions, focusing 
on LLVM infrastructure.

Also the main system programming language on Apple systems is 
Objective-C, with reference counting, and officially deprecated 
as of WWDC 2022 during the state of platforms keynote.