On Monday, 6 June 2016 at 14:27:52 UTC, Steven Schveighoffer wrote:
> I agree. It's telling that nearly all real-world examples we've seen (sociomantic, remedy games, etc.) use D without GC or with specialized handling of GC.

I doubt either of the two you named would change, but I wonder how different the tenor of conversation would be in general if D's GC wasn't a ponderous relic?

-Wyatt

On 06/06/2016 01:49 AM, Ethan Watson wrote:
>
> I linked my DConf talks on a games industry forum, and the first
> response was that "It looks like a poor man's Rust". A notion I quickly

The games industry (with some exceptions) has a very deeply rooted mentality of "$$$ matters, everything else is teenagers hacking in their basement". Naturally leads to: "Rust -> Mozilla -> $$$ -> Valid" vs "D -> Volunteers -> Kids dinking around -> Worthless bullcrap". Honestly, I wouldn't even bother trying with that crowd. Let them circle the drain with their neverending spiral of ballooning-costs.

On Monday, 6 June 2016 at 15:06:49 UTC, Carl Vogel wrote:
> I believe a big issue for D, and for any not-mainstream language, is being straight about what works and what doesn't. D is not alone in this, but I often feel I'm sold on features that I later find out are not fully implemented or have big holes in them. The limitations themselves aren't the problem---the trust is the problem. I never know if I can tell someone else "D can do that" safely (turning off the GC is a good example---it took me weeks of reading forums and documentation to see how practical that really was after initially reading that it was straightforward.)

I completely agree with this point.  I read TDPL cover-to-cover,
and got excited about writing a large, complex, multi-threaded
program in this language.  Then I started to look at Web resources,
and read http://p0nce.github.io/d-idioms/#The-truth-about-shared .
Suddenly it looked like the language was far less stable than I had
believed, and that realization put the brakes on my investing time
in this direction without a lot more investigation.

On Monday, 6 June 2016 at 08:15:42 UTC, Russel Winder wrote:
> On Sun, 2016-06-05 at 19:20 -0700, Walter Bright via Digitalmars-d wrote:
>> […]
>> 
>> * The garbage collector eliminates probably 60% of potential users right off.
>
> And i bet over 80% of them are just saying this based on zero evidence, just prejudice.
>
> Go went with the attitude "Go has a GC, if you cannot deal with that #### off". Many people did exactly that and the Go community said "byeeee". Arrogant this may have been, but Pike, Cox, et al. stuck to their guns and forged a community and a niche for the language. This then created traction. Now GC in Go is not an issue.

GC in Go is not an issue, because in Go the concurrent GC is basically what it has to offer in addition to builtin decent HTTP and cloud-server adoption.

GC is Go would have been a big big issue if Go was not designed for it or tried to present itself as a system level programming language.

For performance you would still not use Go, you would use either C++ or Rust. But few servers in the cloud need those extra 20%.

On 06-Jun-2016 12:16, Walter Bright wrote:
> On 6/6/2016 1:15 AM, Russel Winder via Digitalmars-d wrote:

> Paying attention to our existing users is a much more reliable source of
> information.

Can't agree more. In fact, I'm tired of discussions that revolve around winning appeal of some existing crowd. What we should do instead is help our users do what they already are doing. The resulting top-notch products would be our best marketing.

-- 
Dmitry Olshansky

On Monday, 6 June 2016 at 04:24:14 UTC, Jack Stouffer wrote:
> On Monday, 6 June 2016 at 02:20:52 UTC, Walter Bright wrote:
>> * Documentation and tutorials are weak.
>
> I never understood this, as I've always found D's docs to be pretty average.

If you understand why they are "pretty average" you can imagine what would make them better, that gives you two reference points from which you can extrapolate back to a point at which they are "fairly crap".

"fairly crap" on the graph is where new users come in because...

1. They are not yet fully invested in D, so do not have the inherent bias of a convert.
2. They do not have long familiarity with the docs.

All that aside, it doesn't actually matter what you think or whether you understand why it is a common complaint. It is simply a fact that a lot of new users find the documentation to be "fairly crap". So you can either choose to...

1. Flap your hands and bury your head in the sand.
2. Say it doesn't make sense, these people must be morons.
3. Fix the documentation to make it more accessible to new users.

1 and 2 are the current solution from what I can see.

On Monday, 6 June 2016 at 18:21:49 UTC, Johnjo Willoughby wrote:
> On Monday, 6 June 2016 at 04:24:14 UTC, Jack Stouffer wrote:
>> On Monday, 6 June 2016 at 02:20:52 UTC, Walter Bright wrote:
>>> * Documentation and tutorials are weak.
>>
>> I never understood this, as I've always found D's docs to be pretty average.
>
> If you understand why they are "pretty average" you can imagine what would make them better, that gives you two reference points from which you can extrapolate back to a point at which they are "fairly crap".
>
> "fairly crap" on the graph is where new users come in because...
>
> 1. They are not yet fully invested in D, so do not have the inherent bias of a convert.
> 2. They do not have long familiarity with the docs.
>
> All that aside, it doesn't actually matter what you think or whether you understand why it is a common complaint. It is simply a fact that a lot of new users find the documentation to be "fairly crap". So you can either choose to...
>
> 1. Flap your hands and bury your head in the sand.
> 2. Say it doesn't make sense, these people must be morons.
> 3. Fix the documentation to make it more accessible to new users.
>
> 1 and 2 are the current solution from what I can see.

There documentation can also be classified as broken as broken links were quite the annoyance for me. It's a minor inconvenience, but one that has an additive effect every time I encountered one using their site.

That being said. My major complaint is lack of coherent, relevant or useful examples of what a function/type/template is actually useful for. Most are just ripped out of unittests, provide no context, and often use other library calls that aren't really needed to solve a non-common, non explained problem.

On Monday, 6 June 2016 at 13:10:32 UTC, jmh530 wrote:
> On Monday, 6 June 2016 at 05:49:53 UTC, Ethan Watson wrote:
>>
>> Echoing the need for decimal support. I won't use it myself, but I know it's critical for finance.
>
> You can always round something to two digits if you need to.

It's more complicated than that.  Part of what you need is to
be able to declare a variable as (say) having two significant
fractional digits, and have the rounding rules be implicitly
applied when saving to that variable, producing an exact
representation of the rounded result in storage.  And part of
the reason for that is that if you compare "3.499" to "3.501"
(as the originally computed numbers) when only 2 sig figs
should be in play, they must compare equal.  This is very much
unlike what happens with binary floating point, where exact
comparisons are rarely possible due to low-order bit differences.
In commercial decimal-arithmetic applications (think "money"),
the low-order bits are supposed to be discarded for almost all
values that actually represent an amount of currency.  For
reliability of the application, this has to be built into the
data type, not dependent on programmer vigilance.  That is,
just like certain other language features, a decimal type
without implicit truncation would be thought of as "doesn't
scale well".

On Mon, Jun 6, 2016 at 7:13 PM, Ethan Watson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 6 June 2016 at 07:18:56 UTC, Guillaume Piolat wrote:
>>
>> - well there is an AAA game using it now,
>
>
> Replying solely to highlight that Unreal Engine has garbage collected since forever; and Unity is a .NET runtime environment and all the GC frills that come with it. GC in the AAA/indie gaming space is hardly a new concept.

And Unity has had some pretty serious scalability problems that come from this decision and with unreal the garbage collected components are optional, and when epic goes to push performance, they write it in C++.

Having said that there are garbage collectors out there that are realtime friendly, neither Mono nor D as far as I can tell are perform well in this senario.

Personally I would accept either a Garbage collector that guaranteed me better than 5ms latency or manual memory management.

On Monday, 6 June 2016 at 02:20:52 UTC, Walter Bright wrote:
> Andrei posted this on another thread. I felt it deserved its own thread. It's very important.
> -----------------------------------------------------------------------------
> I go to conferences. Train and consult at large companies. Dozens every year, cumulatively thousands of people. I talk about D and ask people what it would take for them to use the language. Invariably I hear a surprisingly small number of reasons:
>
> * The garbage collector eliminates probably 60% of potential users right off.
>
> * Tooling is immature and of poorer quality compared to the competition.
>
> * Safety has holes and bugs.
>
> * Hiring people who know D is a problem.
>
> * Documentation and tutorials are weak.
>
> * There's no web services framework (by this time many folks know of D, but of those a shockingly small fraction has even heard of vibe.d). I have strongly argued with Sönke to bundle vibe.d with dmd over one year ago, and also in this forum. There wasn't enough interest.
>
> * (On Windows) if it doesn't have a compelling Visual Studio plugin, it doesn't exist.
>
> * Let's wait for the "herd effect" (corporate support) to start.
>
> * Not enough advantages over the competition to make up for the weaknesses above.

Tutorial, tutorials, tutorials ....

Serach youtube for D tutorials and you will find none that is helpful to many people. Check rust tutorials, yeah .... JavaScript tutorials, abundance. Go tutorials, plenty..... Java tutorials, yeah.

Clearly there seem to be a problem with tutorials.