DIP1000 observation

[H. S. Teoh]

On Mon, Aug 26, 2024 at 08:27:31PM +0000, Bruce Carneal via Digitalmars-d wrote:
[...]
> My observation was/is that DIP1000 is overly complex for the value
> provided.
[...]
> There are three paths forward.  In my order of preference these are:  1)
> rethink the whole thing from scratch  2) drop dip1000 and just live with
> gc/@trusted/... and 3) keep patching and whacking and trying to convince the
> D community that DIP1000 is worth it.
[...]

My initial reaction to dip1000 was reservedly positive.  Then it became
disappointment, as the number of discovered loopholes and unhandled
cases grew.  Finally it settled into indifference, since I don't need
any of it in my own code.

It feels like D is trying too hard to be what it isn't. The original
design with GC was clean, ergonomic, and productive. This is the core of
D that still constitutes the major reason why I'm still using it.  Then
the @nogc crowd showed up, and we bent over backwards to please them. As
a result, the language was bent out of shape with attribute soup and
half-solutions to the wrong problems that did little to improve the
experience of existing D users, while still failing to please the GC
objectioners.  The past few years' of language extension efforts have
felt like a lone wolf clawing at the rest of the universe as it sinks
deeper and deeper into a hole it never needed to fall into, while its
primary strengths were left stagnating.  The parts of D that are good
have not improved much, in spite of gaps and corner cases remaining
unfixed over the past decade, while new features that were important
only to a minority of users have been tacked on one after another, never
really succeeding at making the splash they were intended to make, and
only adding more mental load to users who don't need them, and over time
just fading into the corner of obscurity of Yet Another Incomplete D
Feature.

I feel like saying that it's time for D to admit that it can't be all
things to everyone, and to take a stand and decide what it wants to be
-- a GC- at safe, ergonomic language with language features geared towards
modern GC algorithms, or a low-level, Rust-style manage your own memory,
bare minimum C replacement.  But unfortunately I lost confidence that
the leadership would be able to take on such a decision effectively, so
this is probably all I'll say on this subject.


T

-- 
People tell me I'm stubborn, but I refuse to accept it!