On Friday, 6 October 2017 at 21:12:58 UTC, Rion wrote:
>
> I can make a few simple demos and have D use by default 5 to 10 more memory then the exact same C or C++ program. While D does not actually use it ( its only marked as allocated for the GC ), it does not dispel the notion or feeling of people that a GC = bad.

You can configure the GC to deal with that [1].

>
> Other aspects like being unsure when the GC will trigger can also influence people to a non-gc language.

In general: The GC can only trigger when you request memory from it.
W.r.t to the current GC implementation, it will trigger when it doesn't have enough memory to fulfill an allocation request.
In short: You're always in control of exactly when GC pauses can occur. I recommend the GC series for further information [1].

[1] https://dlang.org/spec/garbage.html#gc_config
[2] https://dlang.org/blog/the-gc-series/

On Friday, 6 October 2017 at 17:14:51 UTC, Rion wrote:
> https://www.quora.com/What-is-your-review-of-D-programming-language
>
> It seems that D still has the GC being mentioned up to today.
>
> Maybe its better to move the standard library slower to a non gc version in the future...

as a d user, i do not give a single flying fuck about manual memory management. i love gc. period. please let gc be my guest and clean up everything for me. i have other problems like d / dmd / phobos failing me on freebsd; vibe.d working amazing on linux and throwing some random shit on freebsd.

d is better than java, let alone c++. they both are crap. garbage. incredibly explicit and verbose. yet they get work done for other people. and these people, since the inception of d are throwing random arguments against d. they never ran out of arguments. it was two std libs, it was two d versions, it was lack of 3rd party libs, it was lack of giant corp support, it was lack of community / resources, it was and it will be something for those people. until they decide to shut the fuck up and actually give d a try. just like great people we get here everyday.

a big problem of d is that it is a play-dough for many people here. they don't run into problems with d because they are mostly not eating their own dog food or incredible experts at d. (remember qtd guys?) if we have 100 wtf moments per hour, they probably have like 1-2 per year. they do more abstract stuff rather than concrete stuff. (atila & co, manu, sociomantic people, jacob and some more are exceptions). they are blind to newcomer problems. they also have prejudices like assuming you know all the low level stuff beforehand.

when your beloved language (or its toolchain) screws things up for the app you wrote and deployed and will be used by millions of people per year, you have more problems than you imagined earlier and gc is not one of them.

On Friday, 6 October 2017 at 18:42:02 UTC, H. S. Teoh wrote:
> On Fri, Oct 06, 2017 at 06:09:58PM +0000, Ali via Digitalmars-d wrote:
>> The reputation is D's GC is slow, and Manual Memory Management is fast
>
> The first point is valid (when are we going to get a better GC? :-/), but the second is questionable.

Have there been studies quantifying the performance of D's GC relative to other GC implementations? My anecdotal experience is that D's GC can have undesirable latency behavior (long pauses), but throughput appears good. Of course, quantified metrics would be far preferable to anecdotal observations.

--Jon

On Friday, 6 October 2017 at 17:14:51 UTC, Rion wrote:
> https://www.quora.com/What-is-your-review-of-D-programming-language
>
> It seems that D still has the GC being mentioned up to today.
>
> Maybe its better to move the standard library slower to a non gc version in the future...

WIP:

https://github.com/libmir/mir-algorithm
https://github.com/libmir/mir-random
https://github.com/libmir/mir-cpuid

On Saturday, 7 October 2017 at 01:00:41 UTC, Jon Degenhardt wrote:
> On Friday, 6 October 2017 at 18:42:02 UTC, H. S. Teoh wrote:
>> On Fri, Oct 06, 2017 at 06:09:58PM +0000, Ali via Digitalmars-d wrote:
>>> The reputation is D's GC is slow, and Manual Memory Management is fast
>>
>> The first point is valid (when are we going to get a better GC? :-/), but the second is questionable.
>
> Have there been studies quantifying the performance of D's GC relative to other GC implementations? My anecdotal experience is that D's GC can have undesirable latency behavior (long pauses), but throughput appears good. Of course, quantified metrics would be far preferable to anecdotal observations.
>
> --Jon

Have you tried running the GC instrumentation on your tsv utilities? That might make for a very interesting blog post.

On Saturday, 7 October 2017 at 03:15:41 UTC, Laeeth Isharc wrote:
> On Saturday, 7 October 2017 at 01:00:41 UTC, Jon Degenhardt wrote:
>> Have there been studies quantifying the performance of D's GC relative to other GC implementations? My anecdotal experience is that D's GC can have undesirable latency behavior (long pauses), but throughput appears good. Of course, quantified metrics would be far preferable to anecdotal observations.
>>
>> --Jon
>
> Have you tried running the GC instrumentation on your tsv utilities? That might make for a very interesting blog post.

Well, I have for the tsv utilities and some other programs. That's what's behind my observations. While interesting, I don't think I have enough definitive data to draw conclusions for a blog post. Two specifics:
(1) GC profile data shows long max pause times in several benchmarks. However, where it has occurs it's clearly associated with very large AAs. It may not be representative of more common use cases. (There is more quantification I could do here though.)
(2) The benchmarks I've run are all on throughput oriented tasks. In these the D programs have compared well to other native compiled programs, mostly using manual memory management. I think this does say something to the effect that choosing good algorithms and memory use approaches is usually more important than the GC vs manual memory selection. And, it is consistent with a good throughput story for D's GC, but is hardly a direct comparison.

On 10/6/17 14:12, Rion wrote:

[snip]

> When every new languages besides Rust or Zig are GC. That same "flaw" is
> not looked upon as a issue. It seems that D simply carries this GC
> stigma because the people mentioning are  C++ developers, the same
> people D targets as a potential user base.
>
> D can have more success in targeting people from scripting languages
> like PHP, Ruby, Python, where the GC is not looked upon as a negative.
> The same effect can be seen in Go its popularity with drawing developers
> from scripting languages despite it not being there intention.
>
> I always felt that D position itself as a higher language and in turn
> scares people away while at the same time the people it wants to
> attracts, with most are already set in there ways and looking at excuses
> to discredit D. The whole C++ has all of D features and does not need a
> GC / GC is bad excuse we see in the quora.com posting fits that
> description ( and not only there, also on other sites ).

What if we stop focusing on the C/C++ people so much? The like their tools and have no perceivable interest in moving away from them (Stockholm Syndrome much?). The arguments the use are primarily meant as defensive ploys, because they compare everything to C/C++ and when it doesn't match in some way or another the other language must be deficient. They've already decided that C/C++ is the meter stick against which all other languages are to be judged. Unsurprisingly, nothing that is NOT C/C++ meets their exacting demands.

I saw we ditch the lot and focus on the large languages where D can get some traction (C#/Java).

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

On 10/6/2017 10:19 PM, Adam Wilson via Digitalmars-d wrote:
> What if we stop focusing on the C/C++ people so much? The like their tools and have no perceivable interest in moving away from them (Stockholm Syndrome much?). The arguments the use are primarily meant as defensive ploys, because they compare everything to C/C++ and when it doesn't match in some way or another the other language must be deficient. They've already decided that C/C++ is the meter stick against which all other languages are to be judged. Unsurprisingly, nothing that is NOT C/C++ meets their exacting demands.
>
> I saw we ditch the lot and focus on the large languages where D can get some traction (C#/Java).

Or recognize that painting huge diverse groups as if there's a single brush with which to do so is a huge fallacy.  Consider that the two leaders, as well as a large number of the contributing developers, come from the c++ community and that's not a bad thing, but rather a big part of _why_ they came to D.

As always, focusing on the users of the language tends to pay a lot more dividends than focusing on nay sayers.  Luckily, that's how things tend to proceed here, so yay for that.

On Saturday, 7 October 2017 at 06:19:01 UTC, Brad Roberts wrote:
>
> As always, focusing on the users of the language tends to pay a lot more dividends than focusing on nay sayers.  Luckily, that's how things tend to proceed here, so yay for that.
>

Feel free to ignore me then. I'll have to join this conversation as a naysayer: D is too little too late. It should have been competing with C++ since at least the early 90s. C++ should have **been** D.

Do you know why I'm not using D right now? Because I'm already invested in C++. Also I can get a prebuilt C++14 compiler running on a Jurassic-dated FreeDOS; meanwhile you've abandoned Windows XP. Where D doesn't tread, C++ persists unchallenged. What will happen when Microsoft drops Windows 7, are you going to drop it too?

So what can you do now, other than abandon all hope? You could standardize D ("ISO/IEC DLANG:2020"), officially endorse and support an "official" **standalone** IDE for it (so that it won't be a one-man two-user project), and cross your fingers hoping that C++ will run out of steam before D does.

Or, you can continue talking about GC and call me a troll. In which case, I'll be under yonder bridge.

On Friday, October 06, 2017 23:19:01 Brad Roberts via Digitalmars-d wrote:
> On 10/6/2017 10:19 PM, Adam Wilson via Digitalmars-d wrote:
> > What if we stop focusing on the C/C++ people so much? The like their tools and have no perceivable interest in moving away from them (Stockholm Syndrome much?). The arguments the use are primarily meant as defensive ploys, because they compare everything to C/C++ and when it doesn't match in some way or another the other language must be deficient. They've already decided that C/C++ is the meter stick against which all other languages are to be judged. Unsurprisingly, nothing that is NOT C/C++ meets their exacting demands.
> >
> > I saw we ditch the lot and focus on the large languages where D can
> > get some traction (C#/Java).
>
> Or recognize that painting huge diverse groups as if there's a single brush with which to do so is a huge fallacy.  Consider that the two leaders, as well as a large number of the contributing developers, come from the c++ community and that's not a bad thing, but rather a big part of _why_ they came to D.
>
> As always, focusing on the users of the language tends to pay a lot more dividends than focusing on nay sayers.  Luckily, that's how things tend to proceed here, so yay for that.

+1

Yeah, overall, most of the major contributors seem to have come from a C++ background, and a lot of the folks who actively comment do as well. We really don't seem to have any problem attracting folks from the C++ community. It's just that there are plenty of folks who would prefer to continue to use C++ or end up gravitating to a language that isn't C++ or D. But we still have plenty of C++ folks among those who decide to use D.

Honestly, I've gotten to the point that I don't care much about trying to appeal to folks who complain about D. If we just make the language the best that we can, that will attract folks - that's largely what's attracted them in the past. Sure, we could and probably should do better with marketing D, and some of the complaints that get leveled at the language are valid and should be addressed, but trying to convince folks who are already convinced that they don't like D just doesn't seem like a good way to spend our time and energy.

Complaints from folks not using D _can_ help shows us areas in which we're deficient, but they're not necessarily right, and they're not our actual user base.

And really, what we need is a good language with good tools that supports a vibrant community of those who want to use it. We want that community to grow, because it will help the language and make it easier to get jobs using it, but it's not like we need to convince the whole world to use D - not to mention that there are classes of folks that we don't want; their views and goals just differ too much from ours, which is part of why having a diverse set of languages out there can actually be valuable. Different folks prefer different languages, and trying to get everyone to agree is never going to work. As long as D is sucessful enough that those of us who want to use it can use it and do what we need to get done, then that should be plenty. If more folks decide that they like what D's offering, then great. If they prefer C++ or C# or Rust or whatever, then they can have fun doing whatever they need to do with those languages, and we won't have to make changes to D just to make them happy.

- Jonathan M Davis