D is our last hope

[IGotD-]

On Wednesday, 6 December 2023 at 02:32:20 UTC, H. S. Teoh wrote:
>
> This is wrong, slices do not depend on gc.  *Appending* to 
> slices does (because you have to allocate memory to store the 
> result), but you can pass slices around @nogc code no problem. 
> Taking slices of an existing array (which need not be 
> GC-allocated) is also @nogc. In fact, most of std.algorithm, 
> std.range, can be used with @nogc, the primary blocker there is 
> Exceptions which are GC-allocated.
>
> (Incidentally this is why there was talk about @nogc Exceptions 
> a while back, the idea being that once we get rid of GC 
> dependency for Exception, then basically all of std.algorithm 
> and std.range would be usable in @nogc.)
>
>
> T

True but D has this duality between slices and dynamic arrays and 
they are sometimes hard to distinguish and there can be 
allocations underneath when you least expect it.

For me the problem with D isn't really GC but rather the type of 
GC. For embedded systems memory allocations are fine but the huge 
amount of instrumentation in order to get the GC to work is 
unacceptable (stopping threads, reading registers, reading TLS 
etc). The default GC is also too old and not up to the task for a 
modern desktop/laptop/server computer systems. D was created when 
dual core processors was the coolest thing for desktops. Now 
normal computers have up to 32 cores and multithreading is more 
common. Stopping 32+ threads takes time as is a really ugly 
approach. Therefore D needs to evolve in order to accommodate for 
a more variety of GC types and not only the stop the world type. 
Now it only supports one GC type which is a design error built 
into the language/library.

Honestly, I couldn't care less about @nogc even if I'm doing 
embedded systems. The embedded systems that are so memory 
constrained that you have avoid do memory allocations, then 
better C or C alone is the obvious choice for those systems, not 
using the D library at all.