On Friday, 15 October 2021 at 15:42:13 UTC, IGotD- wrote:
> The biggest obstacle is that D has no fat pointers. It has only pointers which is enough when you have tracing GC but not enough if your pointers requires extra metadata.
This is one of the biggest mistakes in D which limits the possibility to change GC type. Other languages like Nim have a reference types which is a fat pointer type. Nim has gone through more GC types in a shorter time than D.
Fat pointers come at a cost though which might be extra dereferences as your data is an inner pointer member. In practice this is already possible in D as a library solution. Problem is that you cannot easily change Druntime/Phobos to also use your custom GC.
Yeah, what I was proposing is not actually for adding custom GC types, it is for gradually phasing out the GC (for libraries) and maybe replace it with some reference counted type like Rust has.
When people complain about GC in D it's mostly because the library ecosystem is by default @YesGC. TBH I like having a GC and using it when I don't care about memory usage or speed. This mostly when I use D as a Python replacement and it does its job well.
The problem is when I want to use D as a C++ replacement. When I try to do that, I can't D libraries that are not @nogc. I want library developers to design their interfaces after considering allowing the usage of different allocators. Because if that happens then I could pass the GC as the allocator parameter and not care about memory management, or maybe I want to pass my own arena allocator when I'm thinking about cache locality or whatever. Otherwise we're risking two different library ecosystems coexisting (one @nogc and one @yesgc) and that means we'll never have a good library ecosystem.
Just let the application developers pass whatever allocator parameter into the libraries (and actually make the stdlib work this way to set an example).
If the current situation persists, D is just "C" or "Go" with more features and much fewer libraries.
I'm okay with D not having the ecosystem of C (or Rust, or Go) and building everything from ground-up, most people wouldn't be. Don't tell me we have great interop with C and C++, I'm using D because I want to minimize my exposure to C & C++.
I hope the situation changes, because if it doesn't Zig will eat D's lunch even though it is actually a worse language (with probably a better ecosystem). Or maybe Jai will if the situation doesn't change before Jai is released (and everybody knows it won't be released for years, still). That'd be especially saddening since Jai is actually just D with different syntax, no GC and more powerful CTFE. That's literally it.
Permalink
Reply
