On Thursday, 23 August 2018 at 05:37:12 UTC, Shachar Shemesh
wrote:
Let's start with this one:
https://issues.dlang.org/show_bug.cgi?id=14246#c6
The problems I'm talking about are not easily fixable. They
stem from features not playing well together.
One that hurt me lately was a way to pass a scoped lazy
argument (i.e. - to specify that the implicit delegate need not
allocate its frame, because it is not used outside the function
call).
The only real problem with D is that it's a language designed with
GC in mind, yet there are numerous attempts to use it without GC.
Also, supporting GC-less programming gets in the way of improving
D's GC (which is pretty damn bad by modern standards).
That's the only real technical problem.
For example, the "bug" above just means that D doesn't support
RAII
(in the C++ sense). That's hardly a *fatal flaw*. Lots of
languages don't
support RAII. Python, Java, C# - tons of code were written in
those.
And yes, most of those just use GC to dispose of memory - other
resources
are rarely used (compared to memory) and it's not a problem to
manage them
manually.
You also mentioned lazy parameters allocating... GC thing again.
Just
allocate then? No?
IMO, if getting the maximum number of users is the main goal, D
is indeed
going the wrong way. It would be better to get rid of @nogc,
betterC, dip1000,
implement write barriers and use them to improve GC. Martin Nowak
(I think)
mentioned that write barriers will decrease performance of D
programs by 1-5%.
Seems like a small price to pay for better GC with shorter
pauses. It would also
probably be simpler technically than stuff like dip1000 and
rewriting Phobos.
Of course, maximizing the number of users is not the only goal,
or even the
main one. My understanding is that Walter wants a "systems
language" with
"zero cost abstractions". Well, it's very well possible that D's
design
precludes that.
Other than memory management, I don't see any real fundamental
problems.
