Why do you continue to use D?

[Manu]

On Fri, Jun 5, 2020 at 3:30 AM Dibyendu Majumdar via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On Friday, 5 June 2020 at 02:44:17 UTC, Manu wrote:
>
> > Back on-topic; I still use D because I just can't stand C++,
> > and I somehow fundamentally believe D can 'get there'... but
> > god is it a hard and frustrating road! Eternally so close, but
> > always juuuust misses the mark. Maybe one day we'll land the
> > shot >_<
>
> In my opinion there will always be that one missing feature that
> prevents D from getting there. In other words, if features were a
> stopping factor then how did anyone ever use C++ 10 years ago?
>

I feel like I made the case that it's not strictly 'features', so much as
implementation quality and/or the complete package experience.

I mean, one instance of 'new functionality' is extern(C++), which really is
a massive enabler; it creates a migration opportunity which wouldn't be
there otherwise. I've been working for years to improve C++ interaction and
make it comprehensive and useful. It hasn't been on my list of key
struggles recently. We do need to get on top of move construction though...
but it's not holding me back personally.

`shared` though, that's been in a weird limbo state for a very very long
time, and in this instance, the key competitive advantage D offers over C++
is that it has `shared` in the type system.
But having that sticker on the box isn't enough, it has to do something
meaningful. It actually has to implement mechanics that help us resist the
kinds of bugs that you experience with shared data.

Even if those _features_ do work, it still needs to pass the tests where it
shows it can fit into an elaborate existing ecosystem. When really basic
things like inline and weak linkage don't work, that's just a kind of super
boring mechanical barrier to successful integration, and there's no excuse
I can make for those. We can make workarounds, but they're embarrassing,
and we should spend our small quota of "disadvantage points" on the key
stuff that's not trivial to fix.

So when I say "always just one thing", it's not features; it might be...
but it's often also implementation quality, or binary environment
integration issues, or build issues, or tooling issues... unfortunately we
must _exceed_ a very high bar set by the C++ to ecosystem be successful.
We're not evaluating which environment is the best experience overall, what
we have to do is *dislodge* a deeply seated establishment by demonstrating
sufficient advantages that it tips a subjective threshold of a businesses
technical directors. They need to do an evaluation, easily recognise the
advantages, and not be nervous.
I think we've been pretty close to having everything we need for a while
now, but what I was saying here is it absolutely needs to WORK... we can't
show that an idea (`shared`) is there but the implementation is broken.
That will be received worse than if it wasn't there at all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20200605/5563a628/attachment-0001.htm>