Things that keep D from evolving?

[Chris Wright via Digitalmars-d-learn]

On Tue, 09 Feb 2016 14:35:48 +0000, Ola Fosheim Grøstad wrote:

> On Tuesday, 9 February 2016 at 13:41:30 UTC, NX wrote:
>> There are several reasons I want to use D rather than C# / Go /
>> something else:
>> - Interfacing with native API without jumping through hoops
> 
> Well, but the hoops are there to get safe and fast GC.
> 
> 
>> - Incredibly high abstraction and meta-programming possibilities with
>> relatively easier syntax + semantics.
> 
> Not incredibly high level abstraction... But I get what you mean. It is
> fairly high level for a low level language.
> 
> 
>> - Having GC (but not a horribly slow one)
> 
> So you want this to be worked on (as D has a horribly slow one)?
> 
> 
>> - Not bound to a specific platform (unlike C#, easier to do
>> cross-platform work in many cases)
> 
> Doesn't C# work just as well as D (or better) with most platforms?

If you develop against .NET on Windows, you have a moderate chance of 
producing something non-portable. If you develop against Mono on Linux, 
you can produce something more portable more easily.

Mono, by the way, has a good garbage collector, and .NET probably has 
better. Mono advertises:

* precise scanning for stack, heap, and registers
* generational collection using write barriers
* per-thread sub-heaps for faster allocation
* multithreaded scanning

I think D could implement all that with a couple caveats.

Write barriers are a problem for real-time code. Right now, we can tell 
you: you can write code with real-time sections as long as you don't 
allocate GC memory in the real-time sections.

If we introduced write barriers, well, the most straightforward way of 
doing that is to use memory protection and install a fault handler. If 
you write to a page that hasn't been written to since the last 
collection, you get a page fault, the kernel dispatches it to your fault 
handler, the fault handler marks a "card" (it sets a boolean 
corresponding to the page you tried to write to). Then the handler marks 
that page as writable and you go on with your day.

Alternatively, the compiler could insert code at every pointer write. 
(This is the deamortized version. Consistent latency, but if you write to 
the same pointer variable a million times between GC allocations, you pay 
that cost a million times more than you really need to.) You would need a 
compiler switch to disable this behavior. That's not likely to happen.

Walter and Andrei would not accept that, since it makes it difficult to 
get bare-metal performance (and also makes it harder to interface with C).

Which leads me to another thing holding D back. What use cases are we 
trying to support? What are we trying to optimize for? Apparently 
everything. That doesn't work. To some extent you can make things faster 
in general, but you'll still end up supporting all use cases moderately 
well and none exceedingly well.

Anyway, another GC issue is supporting generational collection. You need 
a moving GC to make it work efficiently. D could support a moving 
collector, but it would require more runtime type information. (And stack 
maps, but that might be there already. Not sure.) Walter has been 
strongly against adding extra runtime type information in the past.