On Friday, 6 July 2018 at 21:15:46 UTC, H. S. Teoh wrote:
> On Fri, Jul 06, 2018 at 08:16:36PM +0000, Ecstatic Coder via Digitalmars-d-announce wrote: [...]
>> I've never said that this is something smart to do. I'm just saying that this code can perfectly be executed once in a C++ game frame without having to worry for a game freeze, because the string buffer deallocation is done once per frame too.
>> 
>> While with many GC languages, you actually DON'T KNOW when all those unused string buffers will be claimed.
> [...]
>
> Of course, for someone looking for an excuse not to use D, they will always find another reason why this is not sufficient. But that only strengthens the point that the GC is just a convenient excuse not to use D.

Not a good excuse to not fix GC, though.

> Solve that problem, and they will just move on to the next excuse, because the GC is not the real reason; the real reason is probably non-technical. Like good ole inertia: people are lazy and set in their ways, and resist changing what they've grown comfortable with. But actually admitting this would make them look bad, so it is easier to find a convenient excuse like the GC (or whatever else is different from the status quo).

If that's the case, then we are doom. We might just as well forget about getting popular, and instead spend time making the language better.

Like fixing the GC.

(Although I don't quite agree with you. Some people DO resist change, that's why some decades old languages are still popular. But look at the popularity of new languages like Go, and Rust, and the ever-change landscape of front-end development. There're tons of people who adapt certain technology just because it is new, why can't that happen to D?)

>
>
> T

On Tuesday, 10 July 2018 at 17:03:01 UTC, H. S. Teoh wrote:
>
> AFAIK, the current GC does not release memory back to the OS. So you won't see the memory footprint decrease.  However, it does free up memory for subsequent allocations.
>
>
> T

if you put another
int[] x;
x.length = 1024 * 1024 * 128;

After the GC.collect you now get 1GB of memory usage.

My point is, this type of control is not enough control for anyone coming from a non-GC language, so they will point out GC as a problem. And in my opinion with reason.

I´m using my own lib on D with nogc container and other utilities to avoid completly the GC.

Altought I know that is completly possible to use GC and have good performance, I dont think the arguments for it are enough to convince most people.

I find D awesome (and probably will never look at C++ again), but for me you can remove GC completly from the language and it will continue to be aswesome.

(For me, i'm hoping to compile everything that I have with -betterC in the future. Waiting for some bugs related to betterC to be solved)

On Tuesday, 10 July 2018 at 17:39:06 UTC, SrMordred wrote:
> After the GC.collect you now get 1GB of memory usage.

http://dpldocs.info/experimental-docs/core.memory.GC.minimize.html

On Tuesday, 10 July 2018 at 17:44:59 UTC, Adam D. Ruppe wrote:
> On Tuesday, 10 July 2018 at 17:39:06 UTC, SrMordred wrote:
>> After the GC.collect you now get 1GB of memory usage.
>
> http://dpldocs.info/experimental-docs/core.memory.GC.minimize.html

yeah I was looking to this right now on the docs, thks :)

But still, all this knowledge about GC and all this calls to put the memory where you want, will happen automatically most of the time with the old scoped resources/RAII(and unique_ptr/shared_ptr, that D also have).


GC tradeoffs never really paid well for me. (or my mindset is very stuck in the old ways :P)

On Tue, Jul 10, 2018 at 05:25:11PM +0000, Yuxuan Shui via Digitalmars-d-announce wrote:
> On Friday, 6 July 2018 at 21:15:46 UTC, H. S. Teoh wrote:
[...]
> > Of course, for someone looking for an excuse not to use D, they will always find another reason why this is not sufficient. But that only strengthens the point that the GC is just a convenient excuse not to use D.
> 
> Not a good excuse to not fix GC, though.

Of course.  The current GC, while decent, does leave lots of room for improvement.  Unfortunately, while much talked about, not many people are willing to actually put in the work to improve it.  So I'm not really interested in generating more talk, as opposed to action.


> > Solve that problem, and they will just move on to the next excuse, because the GC is not the real reason; the real reason is probably non-technical. Like good ole inertia: people are lazy and set in their ways, and resist changing what they've grown comfortable with. But actually admitting this would make them look bad, so it is easier to find a convenient excuse like the GC (or whatever else is different from the status quo).
> 
> If that's the case, then we are doom. We might just as well forget about getting popular, and instead spend time making the language better.

I have always been skeptical of popularity.  It is neither a necessary nor sufficient condition for improved language quality.  That's not to say we should not invest effort in marketing D... but popularity does not imply technical superiority, and the only reason I'm here is because of D's technical superiority.


> Like fixing the GC.

Nobody argues *against* fixing the GC.  But, who will actually do it? As opposed to the crowds who are very willing to only talk about it.


> (Although I don't quite agree with you. Some people DO resist change, that's why some decades old languages are still popular. But look at the popularity of new languages like Go, and Rust, and the ever-change landscape of front-end development. There're tons of people who adapt certain technology just because it is new, why can't that happen to D?)
[...]

Those who adapt technology merely because it's new, are what I call the bandwagon jumpers. They will flock to the next brand new thing, and then just as readily leave in droves once the novelty has worn off. They are unreliable customers, and I wouldn't build a business based on their continuing support.  Again, popularity is orthogonal to technical excellence.


T

-- 
"I'm not childish; I'm just in touch with the child within!" - RL

On Tuesday, 10 July 2018 at 18:20:27 UTC, H. S. Teoh wrote:
> On Tue, Jul 10, 2018 at 05:25:11PM +0000, Yuxuan Shui via Digitalmars-d-announce wrote:
>> On Friday, 6 July 2018 at 21:15:46 UTC, H. S. Teoh wrote:
> [...]
>> > Of course, for someone looking for an excuse not to use D, they will always find another reason why this is not sufficient. But that only strengthens the point that the GC is just a convenient excuse not to use D.
>> 
>> Not a good excuse to not fix GC, though.
>
> Of course.  The current GC, while decent, does leave lots of room for improvement.  Unfortunately, while much talked about, not many people are willing to actually put in the work to improve it.  So I'm not really interested in generating more talk, as opposed to action.
>
>
>> > Solve that problem, and they will just move on to the next excuse, because the GC is not the real reason; the real reason is probably non-technical. Like good ole inertia: people are lazy and set in their ways, and resist changing what they've grown comfortable with. But actually admitting this would make them look bad, so it is easier to find a convenient excuse like the GC (or whatever else is different from the status quo).
>> 
>> If that's the case, then we are doom. We might just as well forget about getting popular, and instead spend time making the language better.
>
> I have always been skeptical of popularity.  It is neither a necessary nor sufficient condition for improved language quality.  That's not to say we should not invest effort in marketing D... but popularity does not imply technical superiority, and the only reason I'm here is because of D's technical superiority.
>
>
>> Like fixing the GC.
>
> Nobody argues *against* fixing the GC.  But, who will actually do it? As opposed to the crowds who are very willing to only talk about it.
>
>
>> (Although I don't quite agree with you. Some people DO resist change, that's why some decades old languages are still popular. But look at the popularity of new languages like Go, and Rust, and the ever-change landscape of front-end development. There're tons of people who adapt certain technology just because it is new, why can't that happen to D?)
> [...]
>
> Those who adapt technology merely because it's new, are what I call the bandwagon jumpers. They will flock to the next brand new thing, and then just as readily leave in droves once the novelty has worn off. They are unreliable customers, and I wouldn't build a business based on their continuing support.  Again, popularity is orthogonal to technical excellence.
>
>
> T

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.

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.

Just have a look at this one, which is quite famous :

https://www.techempower.com/benchmarks/

I know that many people here will simply tell me that all those personal et external benchmarks are all wrong, etc.

Maybe you are right.

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 ?

On Friday, 6 July 2018 at 15:19:33 UTC, Ecstatic Coder wrote:
> Actually you answer was right even if the point count was not stored as an integer ;)
>
> For C++, the answer is : never.
>
> Two small memory blocks will have to be allocated from the memory pool, which is not smart, obviously, but apart of that, nothing to worry about.
>
> Because there is no garbage collector in C++, memory has to be allocated and deallocated in a continuous manner...

Recently it got somewhat pushed by Electron applications :)

> But for technical aspect like performance, very honestly I'm still not sure of its technical superiority over similar languages.
>

> Just have a look at this one, which is quite famous :
>
> https://www.techempower.com/benchmarks/
>
> I know that many people here will simply tell me that all those personal et external benchmarks are all wrong, etc.
>
> Maybe you are right.
>
> 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 ?

I' quite sure that D can achieve performance equivalence with any other language. I don´t see any reason not to.

About that specific benchmark, not sure vibe.d had some updates since the first time I saw because I remembered people arguing here about why it was not that good on performance. Maybe now it will make better results.

And I agree about the communication part. Altough i like to see benchmarks and like to see the competition part of it their objective is just to point out that "we can do as much as these other guys can".

When benchmarks go slow people say that "benchmark is not everything or are wrong somehow".

But then when D get the fastest regex parser of the world, is all proud :)

But again, I believe that D can be performance competitive in any case.

On Wednesday, 11 July 2018 at 13:57:45 UTC, SrMordred wrote:
>> But for technical aspect like performance, very honestly I'm still not sure of its technical superiority over similar languages.
>>
>
>> Just have a look at this one, which is quite famous :
>>
>> https://www.techempower.com/benchmarks/
>>
>> I know that many people here will simply tell me that all those personal et external benchmarks are all wrong, etc.
>>
>> Maybe you are right.
>>
>> 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 ?
>
> I' quite sure that D can achieve performance equivalence with any other language. I don´t see any reason not to.
>
> About that specific benchmark, not sure vibe.d had some updates since the first time I saw because I remembered people arguing here about why it was not that good on performance. Maybe now it will make better results.
>
> And I agree about the communication part. Altough i like to see benchmarks and like to see the competition part of it their objective is just to point out that "we can do as much as these other guys can".
>
> When benchmarks go slow people say that "benchmark is not everything or are wrong somehow".
>
> But then when D get the fastest regex parser of the world, is all proud :)
>
> But again, I believe that D can be performance competitive in any case.
Sincerely speaking D language does not merit all these criticism. The magnitude of criticism on D language does not really make sense to me. I am yet to see a language so user friendly as D with such power and strength.I trust one day the world will see and know that D is a language build for programmers for great productivity and not just another money making machine

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.