On Monday, 23 February 2015 at 07:19:56 UTC, Paulo Pinto wrote:
Personally I think what matters is getting D's situation
regarding memory management sorted out, regardless out it will
look like in the end.
This is exactly right, either
1. The compiler takes care of allocation/deallocations and makes
refcounting part of the language implementation (but not
necessarily the semantics).
or
2. If allocation/deallocation is not the compiler's
responsibility then RC should be a library solution based on
efficient generally useful counter-semantics build blocks.
A compiler solution for RC and manual allocations is a
firefighter solution where all similar use cases suffers. I.e.
when you want something similar to, but not exactly like what the
compiler provides...
If I am a bit too quick jumping the gun about GC, is that I
have embraced GC languages in my line of work, so I tend to be
aware that not all GCs are made alike and some like the ones
from e.g. Aonix are good enough for real time situations, the
ones someone dies if the GC runs on the wrong moment.
Maybe such GC quality is impossible to achieve in D, I don't
know.
Well, hard real time does not mean fast, it means "bounded
execution time". GC will is not suitable for a lot of reasons
when you want to get the most out of the hardware (just memory
requirements on diskless systems is sufficient to disqualify GC).
When people use the term "real time" on the forums, they usually
just mean hardware-efficient and low latency.
