2 types of D users, both can live together happily if we adjust

[Jarrett Tierney via Digitalmars-d]

I think there have been many good points here. But I'd like to 
reiterate with any language of any size, it comes down to what 
you use in the language. Yes there are experimental features in D 
that are more influx than others, but depending on those features 
are really up to you and your team.

I think what you should do here, is look at what this D core 
means to you (what features you want to be core vs not) Then use 
that set to build the restrictions of how you code your project 
in D with. If you don't want to leverage the GC then design your 
code practices and project code around avoiding the GC and 
anything that uses it. To me it seems with due diligence, you can 
make your own "D core" by limiting what you use to just the small 
subset of features you trust. In the case of avoiding the GC, 
this requires learning what parts of phobos depend on the GC and 
what parts do not. I believe in some cases you can even leverage 
features of the D language to restrict some feature use (like 
enforcing the use of safe and pure).

I use D at a large tech corporation for an internal tool, and I 
can tell you overall I have not run into too many issues with D 
or its standard library. Usually when I find a feature I'm not 
sure about (stability or otherwise) I'll create a test D program 
and test it myself. Depending on the results I decide whether to 
use it or not.

I understand your points about support. When you are in a 
corporate environment of any size, support for your tools is a 
big deal. I got asked this many a time by my management when 
picking D for my project. The way I addressed the concern is more 
about focusing on quality vs quantity. Yes it would be nice to 
have D have a large set of contributors and maintainers, but no 
matter the amount of people, you have to have a good core set of 
contributors that are the experts. D is a perfect example of 
having this, with people like Walter and Andrei behind it (and 
many more). It is the nature of open source software, that leads 
it to the fragmented development model (engineers only working on 
the parts that interest them), but its also the project leads 
that pull everything together. I actually found that change and 
progress in the language for me inspires more faith in the 
language. Yes it introduces some noise in bug count and a 
developers workload in keeping up, but at the same time it keeps 
the language moving forward.

Hope this helps in some way

-Jarrett

On Saturday, 29 November 2014 at 17:26:30 UTC, Vic wrote:
> On Friday, 28 November 2014 at 23:06:15 UTC, Mike wrote:
>> On Friday, 28 November 2014 at 20:20:55 UTC, ketmar via 
>> Digitalmars-d wrote:
>>
>>> this has an easy solution: just stick with the chosen D 
>>> version: nobody forces anyone to upgrade.
>>
>> Amen.
>
> Here is the problem w/ that:
> Lets stay that we use GDC (because of debugger) equivalent of D 
> 2.066(or whatever) for ~ year.
>
> In essence, we check out of the D community. And when we come 
> back, we find that the D community pool has not grown (due to 
> some of the challenges we found). This means our project is not 
> developed in an unsupported language, and we have to port.
> (In forums I see maintainers talking about GC in core. I think 
> that hooks for ref. counting should be in core, but move the 
> implementation for the average case downstream. Plus many other 
> things. To me, as a manager, figure out what your resources to 
> be good at it, and no more).
> I want to D, and the only way I see that is smaller D and the 
> only way I see that is via a split so that the pool can grow.
>
> Cheers,
> Vic