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 happens. 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". T -- When solving a problem, take care that you do not become part of the problem.