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.
I am a D user since probably 6 months now, I can give you my list from the point of view of a game dev.

I concentrate on the negatives

* The garbage collector eliminates probably 60% of potential users right off.

I think that is mostly true, while it is possible to avoid the GC it is not easy. The biggest problem is that you would need to use something like unqiue_ptr and shared_ptr.

While you can create this, almost nothing in Phobos works with non copyable types. Unqiue and RefCounted both still use the GC and Unique can't be used (any?) container in Phobos currently. You can't even use writeln on it, because almost anything in Phobos "copies" behind your back.

This makes avoiding the GC not really practical unless you are recreating a lot of stuff from scratch and make it move aware. I don't think many want to do this on their own.

* Tooling is immature and of poorer quality compared to the competition.

Honestly I think most languages have very poor tooling but D's is especially bad. I say that without any anger nor do I want to point fingers. I basically use D without any tooling right now except GDB and only use DCD for autocompleting import statements.

* Error messages

I think most error messages are actually not bad, but some error messages especially compile time lambdas that are passed into templates are especially bad. Most of the time you literally get no message at all if the error message is inside that lambda.

* Compiler not written in D

DMD backend is not open source and is written in(C++?). ldc is written in C++.

I don't think that is a big issue now, but at the time of evaluating D I was mostly wondering why D's compiler weren't implemented in D itself.

* Long standing issues

There are so many long standing issues in the bug tracker that also made me wonder how active the community is in fixing stuff. Most issues that I encountered where phobos issues that I worked around by creating my own stuff. Like a zipped range not being able to mutate its elements.

At one point I will try contribute all this stuff but my implementations use a lot of stuff that I have written myself and are not currently in phobos.

* Size of community and getting help

I think D's community is very helpful and we have a few experts that are answering my questions on stackoverflow very often.

But you usually have to wait for some answers quite some time. For example most questions have already been answered for C++ and if you have some advanced question for C++ you usually get an answer in a matter of minutes.

I think D is a amazingly well designed language and if we could "fix" tooling(autocompletion, renaming, goto definition etc), gc and error messages, I think the other issues would be fixed indirectly by having more users.

On Monday, 6 June 2016 at 09:16:45 UTC, Walter Bright wrote:
> On 6/6/2016 1:15 AM, Russel Winder via Digitalmars-d wrote:
>>> * Safety has holes and bugs.
>>
>> Then so does C, C++ and Rust, so this is just a comment made because it
>> can be made and sounds bad. Bad enough to salve the conscience of the
>> speaker as to why they are not already using D.
>
> It's pretty clear when they say that, and then continue using C++ which has no safety, that safety isn't the real reason.
>
> Reminds me of an anecdote Andrei is tired of. In the 80s, a C++ developer said that compilation speed, speed, speed is the most important thing in a C++ compiler. This went on until it was pointed out to him that he was using Microsoft C++, which was the slowest at compiling by a factor of 4.
> Clearly, what was actually most important to him was a name brand compiler (social proof), but he needed a more palatable reason, so he just latched on to one without much thought.
>
> We have to be careful about being led down the garden path by people who say "I'd use your product if only it did X." I have a lot of experience with that, and it's very rare that they'll use it if you do X. They'll just respond with "yeah, ok, but what I really need is Y." This process never ends. Sometimes it's because they're embarrassed by the real reason, sometimes they just take pleasure in you dancing to their tune.
>
> Paying attention to our existing users is a much more reliable source of information.

I think this is a really important point and I 100% agree with Walter. Also, the idea that more people will adopt D if you just "get rid of the GC" ignores the fact that you don't just "get rid of the GC," you replace it with another memory management scheme (manual, RAII, RC). If you replace all the parts of the language and phobos that rely on GC with, e.g., a poor implementation of RC, then you're just going to get another round of complaints, and no real adoption.

In my experience, GC complaints are split between existence and implementation. Some folks are dead against and GC code, others just don't like how the current GC works. In my world---which is not AAA gaming or HFT, but is still very concerned with performance---a GC is tolerable, but a clunky stop-the-world GC with big unpredictable pauses is less so. Having a high quality GC that can be avoided (with some agreed-to and well-documented limitations) would be great.

My concern is that the kill-the-GC craze is going to fall into a second-system trap, and be replaced with buggy half-implementations of, say RC, that I can't rely on, or will be combing through piles of stale bug reports about in 6 months.

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.)

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.
> [...]
> * The garbage collector eliminates probably 60% of potential users right off.

Curious of the progress/plan for RC. From the autodecode thread sounds like RC-string is still in the works. How's that effort coming along? I am guessing it may be guiding the implementation of an RC design for D. If you and Andrei have a working design perhaps it could be shared (no pressure, just curious since it is a tough problem to solve). Perhaps sharing a plan on this front could dispel some of the negativity attached to the GC?

As an aside, I am not opposed to garbage collection. Working with D the little that I have has helped me to be understand better how to avoid allocating memory and how allocation works with memory management algorithms. That is great. But I still do not have a clear idea of how to completely avoid GC and do just manual memory management in D. Perhaps a short tutorial of this could be presented front-and-center on the website.

Joe

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.

Hello,

why not a poll, and ask the community that they want first.
- tiny web library from vibe.d will not be complicated
- improve documentation, the same
- tour.dlang.io improvements
- make an editor work properly on all platforms YES
- weekly tutorials. (that will be 30 until the end of year)
- more noise on how to use proper dlang. dfmd, dub, dscanner.
- make the website much friendly. Hire some freelancers and make the website nice!

#makedlanggreatagain!

On 06/06/16 10:02, Jack Stouffer wrote:
> On Monday, 6 June 2016 at 06:32:15 UTC, Andrei Alexandrescu wrote:
>> These are only a part of our competition. -- Andrei
>
> Sure, I was just remarking on the fact that the amount of complaining
> about GCs is disproportionate to the number of people not using GCs. As
> I said, I think it's more of a meme ("lol D sux cuz the GC") than actual
> C++ users complaining.

I'm not only a C++ user, I am also a D user. And I'm complaining.

Shachar

On 06/06/16 07:17, Adam D. Ruppe wrote:
> On Monday, 6 June 2016 at 02:30:55 UTC, Pie? wrote:
>> Duh! The claim is made that D can work without the GC... but that's a
>> red herring... If you take about the GC what do you have?
>
> Like 90% of the language, still generally nicer than most the competition.
>
> Though, I wish D would just own its decision instead of bowing to Reddit
> pressure. GC is a proven success in the real world with a long and
> impressive track record. Yes, there are times when you need to optimize
> your code, but even then you aren't really worse off with it than
> without it.

Weka thought so too, at first. We said there are two kinds of components where it is okay to use the GC:

* Long living objects (where the GC won't matter, because they are not freed anyway)
and
* very small objects.

The thought was that, with these two constraints, the GC won't matter. We can run it infrequently, and all will be fine.

Turns out, we were very very very wrong.

The problem with the GC is that its run time is proportional not to the amount of memory it frees, but to the amount of memory it needs to scan. This number is vastly different than the first one. Without keeping this number low, the GC freeze time runs into the high milliseconds range.

So we changed course. We are now trying to minimize the total use of GC memory. This, with lots of other tricks, would, hopefully, allow us to get the GC run time to very very very low, maybe even not run it at all.

However, saying that the GC makes you no worse is simply false.

Shachar

On 06/06/16 07:38, Jack Stouffer wrote:

> I never understood the large amount of people on /r/programming
> complaining about the GC when the vast majority of software is written
> in one of the following languages: C#, Java, PHP, Python, JavaScript.

With the *possible* exception of C#, none of those are systems programming languages. D presents itself as one.

Shachar

On Monday, 6 June 2016 at 16:10:29 UTC, bob belcher wrote:
>
> why not a poll, and ask the community that they want first.

I'm not sure poll-driven development is necessarily a good idea. The people leading development probably already have a good sense of the communities' priorities. Also, it's not like all energy will be poured into one or two of them - ideally several could be worked on.

I think a better approach is just listing community priorities and making clear who has responsibility/ownership over them.

On Monday, 6 June 2016 at 05:28:58 UTC, ketmar wrote:
> On Monday, 6 June 2016 at 05:13:11 UTC, Daniel Kozak wrote:
>> You can still unregister your critical thread from GC.
>
> exactly. that's what i did in my sound engine, and it works like a charm: i can enjoy hiccup-less ogg replaying on the background while the main code enjoys GC.

So, did your sound engine 'hiccup' before you did that? Do you think it is acceptable? Does C#, Go, or other languages have this problem out of the box? I could write a hiccup-less sound player in C# without messing with the GC at all and it be fully functional...

D has a GC problem and they never arrive on time and sometimes make a mess. The real problem is no one seems to care except the people that end up with trash all over their lawn.... but isn't that always the case?

On Monday, 6 June 2016 at 10:35:40 UTC, Jacob Carlborg wrote:
> On 06/06/16 04:20, Walter Bright wrote:
>
>> * Tooling is immature and of poorer quality compared to the competition.
>
> What is the competition in this case?

I write a lot of Perl code, and I swear by perltidy to keep
things clean and neat.  Aside from running on full files to
clean up the mess I often inherit, I have a single-button-press
macro in the editor to invoke it on the current block of code.
I would want similar full-featured capability and convenience
from dfmt (or my own dtidy, if I were up to writing it).