On Thursday, 23 August 2018 at 06:34:01 UTC, nkm1 wrote:
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.
+1
Making D a "true" C++ competitor is not going to happen soon.
Even Rust, which IS by definition a true C++ competitor (no GC,
etc), will still find it very hard to replace C++ in its current
niche markets, like embedded and game development.
While putting all the "funded" efforts in making D a *direct*
competitor to GC languages (like Go, Crystal, C#, Java, etc)
would be an achievable goal, IMHO...
