My wish for 2015...

[Xinok via Digitalmars-d]

On Wednesday, 24 December 2014 at 23:14:53 UTC, Delirious wrote:
> On Saturday, 20 December 2014 at 22:11:35 UTC, Xinok wrote:
>> (2) Furthermore, we need to improve the performance of the 
>> garbage collector.
>
> "Performance" is a complex issue in the case of GCs. There is 
> not "highest performance GC", only GCs optimally tuned for 
> certain scenarios. While a simple, imprecise, mark-and-sweep 
> collector like the one used by D right now is not that 
> complicated, modern, industrial GCs are very complex.
>
> There are many decisions to be made and there is no single 
> "right" answer.

A simple philosophy to follow is to "optimize for the common 
case". As I stated, I'm not expecting an optimal solution within 
the next year, just something that's "good enough". There's lots 
of details to work out, but that's not a problem. It's not 
uncommon for discussions here to go beyond 200+ posts, so I have 
no doubt decisions will be made.

> At this point I would like to quote a post about the evolution 
> of the Go garbage collector because Go originally had a 
> primitive GC too but is now far head of D's by any standard:
>
> ...

All the more reason why this issue needs resolution. D was first 
released 13 years ago whereas Go is only five years old and 
already has a far superior garbage collector. I know it's to be 
expected as Google has billions of dollars at it's disposal, but 
all most people see is what they're given.

That's possibly the greatest challenge of D, the fact that it's a 
community-developed language. If you can't get the community to 
agree on specific goals and deadlines, then people will work on 
whatever interests them and it becomes a disorganized mess.

> Replacing the GC with a different one is controversial, for 
> example:
>
>     except for very large heaps, it is unclear whether a 
> generational GC would be faster overall
>     package "unsafe" makes it hard to implement fully precise 
> GC and compacting GC

I'm not saying we need to replace the GC altogether, and that's 
probably an unrealistic goal to achieve within the next year 
anyways. For example, making the GC precise would add a bit of 
overhead but it would also benefit by scanning less memory 
overall (no need to scan ubyte[] for pointers). Furthermore, if 
we stick to the stop-the-world model we have now, there's no 
reason we can't implement a concurrent sweep like Go has. ;-)