On Wed, Jul 11, 2018 at 09:36:25AM +0000, Ecstatic Coder via 
Digitalmars-d-announce wrote:
> Except for Crystal, I think that D is superior to many languages in
> *ease of use* and *expressivity*, and I really like it a lot for that.
> But for technical aspect like performance, very honestly I'm still not
> sure of its technical superiority over similar languages.
> For instance, I'm personally convinced that a Go web server can often
> beat its vibe.d equivalent in technical aspects like raw performance,
> memory consumption, multi-core usage, etc.

Recently, it has been openly acknowledged that vibe.d is not the most
efficient for certain use cases.  I don't know if the problem has been
solved yet, but I assume somebody's working on it.

> And even if benchmarks are always to be interpreted cautiously, when
> several of them lead to exactly the same conclusion as my own tests,
> and with such big margins, it's very hard to completely ignore them.

It's true that benchmarks results should always be taken with a grain of
salt, but that doesn't mean D is already flawless and we don't need to
improve things.  On the contrary, I think there's lots of room for
improvement, which is one of the things that draws me to D, because
here's a chance to contribute something meaningful to a powerful, easy
to use language.  That's the advantage of a true open source project,
where money isn't the driving factor, but people solving real problems
and honing it to be something excellent -- and anyone can participate if
they choose to.

> But in terms of communication, wouldn't it be much more effective that
> the D experts of this forum simply fix the open source code of those
> benchmarks to make D's technical superiority much more obvious, so
> that the decision makers of software development companies, which
> stupidly use the informations of such benchmarks when investigating
> alternative technologies, can more easily suggest to their leadership
> to switch to D ?

This is one of the things about open source / volunteer projects that
may or may not be a good thing (it can be argued both ways).  Since
people aren't getting paid to do grunt work, if nobody steps up to the
plate to fix an issue, it will either just sit there forever, or it will
fall upon Walter and Andrei to get to it, which, given how much is
already on their plate, will take a very, very long time.  And people
will just work on whatever interests them.  Happy D users who don't find
any problems (for THEIR use case) won't have much motivation to
contribute to something that doesn't directly benefit them (or they
don't even use it).  Unhappy D users who *do* find a problem will either
step up and fix it and contribute it so that the rest of the community
benefits, or they will choose not to participate, in which case nothing

I'm not trying to justify this situation, but having observed how things
work around here for the past many years, that's just the way things
work.  Either somebody gets ticked off enough to actually do something
about an issue, resulting in all-round benefits, or they just do
nothing, and nothing happens. (Complaining in the forums doesn't count,
since it has been proven time and time again that this almost never
leads to any actual change.)  This is unlike how most commercially
driven projects work, for obvious reasons, and for better or for worse,
that's what we have to deal with. (Personally I think this is actually a
good thing, but I'm guessing many people will disagree.)

So saying "wouldn't it be much more effective that the D experts of this
forum simply fix the open source code" ultimately won't lead to much
change, for better or for worse.  *Somebody* has to step up to do it.
Expecting somebody else to spend their unpaid volunteer time to work on
something that may not really interest them is, to say the least,
unrealistic.  The solution, as Walter says, is to "be the change you
want to see".


When solving a problem, take care that you do not become part of the problem.

Reply via email to