Worst ideas/features in programming languages?
someguy at mailinator.com
Fri Oct 15 16:21:32 UTC 2021
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
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.
More information about the Digitalmars-d