Idea #1 on integrating RC with GC

[Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>]

On Sunday, 9 February 2014 at 20:15:51 UTC, francesco cattoglio 
wrote:
> I totally agree on this, but the problem here is that
> there are game developers out there, willing to use D. I also 
> see lots of movement from hobbysts. We can't ignore them 
> completely. Undefinedly long pauses are really bad for them, 
> and something needs to be done. Be it in user code, library 
> solution or as core part of the language.

I totally agree with you. I totally agree that the best focus for 
D would be to aim for towards being a kick-ass low level system 
language with programmer directed optimization (compiler hints), 
good memory layout control, and low latency, for medium sized 
code bases, and without historical c/c++ cruft. Because that spot 
is open and it rings a bell... For some reason the D community 
does not pursue it… as a shared goal. And that means D will never 
get there.

I think one needs profiled whole program analysis to get there. I 
think one needs to aim for upcoming hardware architectures. I 
think one need to back it up with programmer specified 
constraints and hints. I think one needs high level optimization 
in addition to low level. I think one needs a very light and 
transparent runtime with tuneable low cost allocation schemes.

I also think one needs to reduce the focus on separate 
compilation with no knowledge about what goes on inside an object 
file and C++/C ABIs. The compiler should have as much information 
available as possible.

Then you also need to slack on C#/Java features, reflection, 
programming in the large, garbage collection and enforced 
correctness. To stay focused. However the goal of D appears to be 
to blend all these thing in one big melting pot. That makes 
things move slowly in a manner where I have trouble seeing the 
vision.

So the outlook today appears to be that D is primarily useful for 
the in-between-spot which is really tools and perhaps some server 
stuff.

> I agree that AAA titles are not the main right now, but this 
> doesn't mean indie projects shouldn't be doable. After all, 150 
> milliseconds pauses are really annoying for pretty much any 
> first person game.

Yeah, it is indeed both uneccessary and undesirable with that 
kind of latency, but if it happens once per hour it has no real 
consequences in most scenarios. For some reason the GC is the 
holy grail of D, so I am just kind of figuring out what the 
benefits/damage is.

Personally I have given up all hope of D becoming useful for 
client side stuff:

1. because of all the resistance in the forum.

2. because C++ portability is hard to beat (android, ios, win, 
pnacl etc)

3. because C++ provides low latency

4. because the capabilities of HTML5 browsers are eating heavily 
into the client space and might change the landscape in a few 
years

I think the perceived D-vision-of-2013 might be useful on the 
efficient-server-side and there the GC actually makes sense every 
once in a while to clean up leaks.

And that is OK too, even thought that space is a bit more crowded 
than the low level space.

Just let's avoid the high profile argument. Be exceptionally good 
at some modest stuff first then expand into other areas next 
iteration.

I think the fallacy is the notion of General Purpose Programming 
Language, as if those actually exist. :-) They don't, because 
human beings are following trends and you need a focused culture 
to sustain the eco system.

So yeah, I agree with you, but I don't see the clearly 
communicated vision and therefore don't believe in the growth of 
a eco system around D for client side programming. :-/