What are (were) the most difficult parts of D?

[H. S. Teoh]

On Mon, May 16, 2022 at 04:00:12AM +0000, cc via Digitalmars-d-learn wrote:
> On Wednesday, 11 May 2022 at 05:41:35 UTC, Ali Çehreli wrote:
> > What are you stuck at? What was the most difficult features to
> > understand? etc.
> > 
> > To make it more meaningful, what is your experience with other
> > languages?
[...]
> Immutability.  Ended up having to do so many hundreds of casts to and
> from immutable(whatever) the amount of mental strain greatly exceeded
> whatever benefits the entire concept is supposed to offer.

If you find yourself having to cast to/from immutable, you're using it
wrong.  Most of my code doesn't have a single mention of immutable in
it, and I don't care. It's there for when it's relevant, if it's not
useful, don't use it.


> Safety?  Performance, in a future compiler version?  I don't know
> where it's at right now.

What about performance?

For anything performance-related, I don't even look at dmd, I use LDC
all the way. DMD is only useful for fast compile-run-debug cycle, I
don't even look at performance numbers for DMD-produced executables, it
doesn't mean anything to me.


> But you'd think I could do something like load some data from disk,
> craft a few objects, mark them as immutable, and shove them in an
> array or associative array without it being a nightmare, but it isn't.

An explicit example would be nice.

I write D programs that process input files all the time, including
stuffing data into AAs and what-not, and it Just Works(tm).  But not
once did I bother with immutable (why should I?).  The most I'd do is to
mark something const (you might want to read up on the difference
between immutable and const -- maybe that's why you had so much
trouble), but even that I don't bother with most of the time. Const in D
has limited utility beyond leaf-node data structures and modules, just
let it be mutable and call it a day.


> Or, having an otherwise mutable class with a member that references an
> immutable class, but can change which immutable instance it's
> referencing, without having to cast away the immutability of the thing
> I'm trying to protect in the first place.  So I just stopped doing it,
> and simply rely on the "just don't make mistakes" practice to avoid
> writing to things that shouldn't be written to now.

Just make things private and use getters/setters to control access. Like
I said, if you find yourself writing lots of casts when using
immutable/const, you're probably doing it wrong.


[...]
> On another topic, the lack of a good "delete" keyword doing what one
> would expect, when there's a perfectly good "new" without its matching
> existential companion.  This, and the ways around it, have already
> been discussed to death though, but banging my head over trying to
> force deterministic memory management into the GC-controlled D
> universe did take its toll on a good year or two of productivity.

Why would you want to force deterministic memory management onto
GC-allocated objects?  Just use malloc/free (or whatever else you
fancy).  Slap @nogc on main() and go from there, if that helps.

IME, most programs don't actually need to care whether their memory is
manually-managed or GC'd.  Many of my programs use GC freely, except in
inner loops where tigher control is needed, then I either preallocate or
use malloc/free.  But only where it actually makes a difference to
performance.  Outside of performance bottlenecks I don't bother with
memory management, just let the GC do its job.


T

-- 
Latin's a dead language, as dead as can be; it killed off all the Romans, and now it's killing me! -- Schoolboy