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. :-/
