On Wednesday, 12 January 2022 at 20:48:39 UTC, forkit wrote:
Fear of GC is just a catch-all-phrase that serves no real
purpose, and provides no real insight into what programmers are
thinking.
"Fear of GC" is just a recurring _excuse_ for not fixing the most
outdated aspects of the language/compiler/runtime.
I have no fear of GC, I've used GC languages since forever, but I
would never want a GC in the context of system level or real time
programming. I also don't want to deal with mixing mostly
incompatible memory management schemes in an application
dominated by system level programming.
In this context a GC should be something local, e.g. you might
want to use a GC for a specific graph or scripting language in
your application.
Do I want a GC/ARC for most of my high level programming? Hell
yes! But not for system level programming, ever.
(Walter has always positioned D as a system level language and it
should be judged as such. Maybe D isn't a system level language,
but then the vision should be changed accordingly.)
It's all about autonomy and self-government (on the decision of
whether to use GC or not, or when to use it, and when not to
use it.
Which essentially is the essence of system level programming. You
adapt the language usage to the hardware/use context, not the
other way around.
You shouldn't be glued to nonsensical defaults that you have to
disable. You should have access to building blocks that you can
compose to suit the domain you are working with.
A GC can be one such building block, and in fact, the C++
community does provide several GCs as building blocks, but there
is no force feeding… Which is why C++ is viewed as a hard core
system level language by everyone and D isn't.
I don't believe people are attracted to D because it has GC.
There are better languages, and better supported languages,
with GC.
Or more importantly; low latency GCs and a language designed for
it!
Also, the idea that 'GC' means you never have to think about
memory management... is just a ridiculous statement..
I don't have to think much about memory management in Python,
JavaScript or Go, but I would also never do anything close to
system level programming in those languages.
You can create very interesting interactive applications in
JavaScript, but then you:
1. Rely on clever system level programming in a very heavy
browser runtime.
2. Use an eco system for interactive applications that is
designed around the specific performance characteristics of the
javascript runtime.
3. Adapt the application design to the limitations of the browser
platform.
4. Get to use a much better low latency GC.
Point 1, 2 and 3 are not acceptable for a system level language…
So that is a different situation. And D does not provide 4, so
again, a different situation.
Cheers!
