Worst ideas/features in programming languages?

SomeGuy 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 
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.


More information about the Digitalmars-d mailing list