On Monday, 18 January 2021 at 12:17:24 UTC, aberba wrote:
If you read the Origin of D book, you would see that the GC was
a desire thing when D was designed probably due to how useful
it is for ... as said, 90% or so of software development. So at
this point, fighting the GC isn't (in my opinion) the right
strategy.
Not fighting the GC, but the whole argument about improving it,
or mix or match, does not work for most developers looking for a
new language. So either there has to be something else or the
language semantics will have to be adjusted to get a better GC.
That is the crux, the GC cannot be significantly improved without
some minor adjustment to the language (with some breaking
changes).
To get there the majority have to be in favour of it. If 50% of
the D community pulls strongly in the opposite direction, then
the GC cannot improve in a meaningful way.
Yes, it is natural that the current D population don't mind the
current GC. Otherwise they would be gone... but then you have to
factor in all the people that go through the revolving door and
does not stay. If they stayed the eco system would be better. So
the fact that they don't... is effecting everyone in a negative
way (also those that har happy with the runtime).
I should also say that I notice your point about improving GC
in D and making it more optional as much as possible for things
that still rely on GC...ARC, etc. 👍
ARC is a pretty big change, so it will depend on library authors
supporting it. It also requires a new intermediate
representation. So I don't think it will happen. Thread local GC
seems most reasonable. As CPUs get more and more threads it
becomes more and more unacceptable to lock all threads during
collection.
The OP was about why programmers don't "like" GC.
Programmers like GC, just not for system level programming. C++
has had the Boehm GC since the mid 90s. Only a tiny percentage
use it. Forget about game engines, many games have game contents
written in Lua and other scripting languages and can live with
incremental GC with very little impact on interaction (you could
use Javascript too). The game engine itself is usually not
relying on GC, just the game content part.
I've been here long enough to see the GC being one of the most
re-occurring issues for discussion (probably due to new users
coming in).
Yes, they come in, but do they stay? If they don't stay, then our
eco system suffers from it.
D would be in a better position by tracking why people leave and
then fix those concerns (if they are related to the
language/runtime).
There's been official posts about how D's style of GC isn't
like that of fully managed languages, how to write nogc code in
D, how to minimize GC, among others.
Yes, but people who are well versed in system level programming
know how to to this already, they just want more hassle than they
get in other languages. And those are also the same people that
would write solid libraries/improve on the compiler. So not being
able to retain those developers is a biiiiig loss.
Now if none of these work for you (for some special reason),
then the long-term strategy might be an alternative runtime and
or std. Which isn't a good answer that thought was worth
it...so I didn't include that.
Actually that is a good answer, if it comes with the appropriate
language changes, like tagged unions and banning conflicting
pointers in unions.
What works for me, is not the issue, but what IS the direction??
Where are we going? That is the real issue.
I am perfectly ok with C++20 for low level programming. I don't
need D for that. It is totally OK if the D community decides to
make it more high level and easier to deal with for newbies who
come from Python.
If none of these work, then I (as in my personal opinion),
don't know what else is available.
I am ok with any one of these alternatives:
Alternative 1: Adjust the language semantics so that the GC can
be improved and accept some breaking changes.
Alternative 2: Switch focus from being a system level language to
becoming more of a high level language.
Alternative 3: Implement ARC.
The other alternatives don't really work. Doing what Rust does is
now 2 years late, it would take 5 years to get there. Doing what
C++ does, does not help. Why would I use D instead of C++ then?
Just pick a direction, because right now, the direction is not
very clear and then progress becomes impossible. No direction,
means no progress...
