On Monday, 18 December 2023 at 16:44:11 UTC, Bkoie wrote:
just look at this i know this is overdesign im just trying to
get a visual on how a api can be design im still new though but
the fact you can build an api like this and it not break it is
amazing.
but what is with these ppl and the gc?
just dont allocate new memory or invoke,
you can use scopes to temporry do stuff on immutable slices
that will auto clean up
the list goes on
and you dont need to use pointers at all.......!!
i honesty see nothing wrong with gc,
I don't think there is any wrong having GC in language either and
upcoming languages also show that as a majority of the have some
form of GC. GC is here to stay regardless.
So what is the problem with D? The problem with D is that it is
limited to what type of GC it can support. Right now D only
supports stop the world GC which is quickly becoming unacceptable
on modern systems. Sure it was fine when when we had dual core
CPUs but today desktop PCs can have 32 execution units (server
CPUs can have an insane amount of of them like 128). Stopping 32
execution (potentially even more if you have more threads) units
is just unacceptable, which not only takes a lot of time but a
very clumsy approach on modern systems.
What GC should D then support? In my opinion, all of them. Memory
management is a moving target and I don't know how it will look
like in 10 years. Will cache snoop be viable for example, will
the cores be clustered so that snoops are only possible within
them etc? D needs a more future proof language design when it
comes to memory management.
Because of this it is important that D can as seamless as
possible support different types of GC types. Exposing raw
pointers in the language for GC allocated type was a big mistake
in the D language design which I think should be rectified. About
all other new languages have opaque pointers/reference types in
order to hide the GC mechanism and so that other GC algorithms
like reference counting can be used.
This is a an F- in language design.
