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
