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

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

On Thursday, 27 November 2014 at 22:58:33 UTC, Vic wrote:
> Something stable for us to lean on.

Breakages are not only caused by experiments. What breakage did you encounter?

On Friday, 28 November 2014 at 20:00:36 UTC, Vic wrote:
> My problem: I have 3 developers(still hiring more) that work for me please lets not use D, it is not stable release to release (and has a bunch of things no one needs).

Do they have concrete examples of instability and how it affected them?

Saying that there are "2 types of D users" is the same as saying "I see the world black and white". :) - It is far from reality. D community has lots of "groups" if you look closely.

Examples:
1) OOP vs functional/declarative group.
2) system programming vs business programming group.
3) no-GC vs GC group. (related to #2).
4) Stable D spec group vs unstable D spec group (what you call "experimental").
Etc.
5) web UI vs "native" UI (based library X where X = Qt, Gtk, FLTK, SDL etc)

Finally, there is "stable D" (D1) but ironically it is not supported as far as I know. There is no D2 version that can be considered stable. - There would be, if D team was organised properly and decided to maintain a stable D2 branch that is free of "things in motion".

What are alternatives? - Make the abovementioned "stable D" branch by yourself, and maintain it in-house. It is really hard to do all this in a truly open project because maintaining this stable branch is IMHO a full-time job.

On Wednesday, 3 December 2014 at 15:52:30 UTC, Dejan Lekic wrote:
> What are alternatives? - Make the abovementioned "stable D" branch by yourself, and maintain it in-house.

Yes, I have started to replace phobos with my own library. It will probably take a man-month to complete. The advantage is that I get my own types for integers, simd and simd friendly containers. The disadvantage is that you end up on an island…

This is exactly what people have done with C++ up to now.

But the real issue is the compiler. If I want to receive bugfixes I will only be able to modify the compiler on the most superficial level, which is the parser and some conditional switches in strategic location in the compiler core (e.g. turning off UFCS). That limits what you can do, but what can be done in the parser is easy to fix, less than 2 weeks of work

So this is possible, but far from ideal IMO.

In perspective: C++ spent ~20 years getting a reasonable standard library in place which has a more narrow scope than D's standard library and C++ had to change the language to make STL usable (and it still is annoying).

> It is really hard to do all this in a truly open project because maintaining this stable branch is IMHO a full-time job.

I don't think maintaining a stable branch is a full time job. The maintainer will only back port bugfixes that are non-breaking (i.e. you don't back port well known bugs with well known work arounds).

The real challenge is to get to a stable release in the first place, because that would probably require a 6 month feature freeze.

To get a feature freeze you will have to get most people to agree on the current feature set being sufficient, which is at odds with the «please break my code» crowd.

What is really needed is a list of issues with assigned priorities that has to be fixed before a feature freeze can be decided on.

That will only happen if someone steps up and take a management role where issues are identified, analyzed, prioritized and followed up with a plan.

On Wednesday, 3 December 2014 at 16:21:03 UTC, Ola Fosheim Grøstad wrote:
> That will only happen if someone steps up and take a management role where issues are identified, analyzed, prioritized and followed up with a plan.

It is also worth noting that in most area of creativity the creators will be too involved with the design to take an "outside look", so it is might be better to have a person without an investment  in the design help out.

When collecting issues one should avoid evaluating the issues. This is a problem with current forum threads. One should collect all unresolved issues raised by various users first. Only after collection is finished should one analyze, and only after analysis should one evaluate.

With no deadline for a stable release commercial related investment in development makes little sense. If you require a stable release to use the compiler in production you need a deadline for the next stable release.

I am convinced this slows D development for no good reason, and I don't agree Open Source is special. A list of issues that needs resolution before the next stable release and a plan to go along with it could make a real difference, IMO.

It is all solved by semver and release discipline - something language authors are strongly against.