www.digitalmars.com         C & C++   DMDScript  

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

reply "Vic" <vic.cvc gmx.com> writes:
There are 2 users I see, those that see it as an experimental 
feature platform and those that use it for real projects (and not 
for experiments).

The 'real project/core' is where we are ( 
http://blog.apakau.com/2014/11/cmg-paper ) and we need a stable 
systems language. From 'real project' people, the people that are 
in the 'experimental platform' currently *shit* where we eat (as 
per my D programmers that work for me, D is big and unstable).
As I see it, the issue is that D is a wide platform(not a small 
lang)  that is hard to maintain with the size of the team. 
(Similar wide platforms feature wise are JRE and CLR, both w/ > 
100 developers). So how many core D developers we have?(*)

A more modern language like Go splits btwn stable 'core' and 
'experimental feature platform', for example no need for core to 
have try/catch, when it can be done downstream:
  - http://github.com/manucorporat/try
This is similar to Linux: kernel and gnu; and what I propose for 
D: to be split up.

This would allow users of *real project* to use a core and people 
that want to have  features could do that downstream: let a 1000 
flowers bloom!

If you are w/ me so far, how big/small should core be?
*Small enough to be maintained by the size of the team at hand 
and no larger. *

Something stable for us to lean on.
Next, is it feasible to split? Std library has much bloat and is 
easy to split up into core and downstream experimental feature 
platform.
That leave the compiler. I am not an expert, but this could be 
done w/ core 'compiler' and the rest in optional pre-processor. I 
think it can be done w/ backwards compatible (just switch GC to 
default off)

I'll say 90% +  should and must be moved to downstream projects. 
This allows for the famous quote: 'fearlessly peer into the gates 
of hell’ - all I’m saying do it downstream, let us build projects 
that can lean on small/simple and maintainable D core.

Lets make D core small please. List of things that are core: char 
arrays.  What else should be core?
The key question in this tread: how small should core D be to be 
maintainable and stable? How can it be split?

http://tinyurl.com/q5t2eag
Nov 27 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Nov 27, 2014 at 10:58:31PM +0000, Vic via Digitalmars-d wrote:
 There are 2 users I see, those that see it as an experimental feature
 platform and those that use it for real projects (and not for
 experiments).
[...] The thing is, based on my observations over the past few years or so I've been here, such grand plans have often been proposed (in the best of intentions, to be sure) but rarely carried out. The thing about D is that if you wish to see something happen, you just have to dig in and *do* something about it. Be the champion of whatever you propose, get on the ground and work it out, make it happen. Contribute code. Help improve the infrastructure. Be the change you wish to see take place. While these forums can be quite entertaining, from my observations most of the animated discourse ultimately results in nothing -- because nobody actually got up to *do* something about it. The stuff that *does* happen often happens in the background where somebody actually did the hard work and wrote the code, pushed the PR's through to acceptance, contributed the hardware to improve the infrastructure, etc., often with little or no activity on the forums. Almost all of the discussions on the forums that have little or no code backing it up tend to just sputter out after everyone's energy has been exhausted, and nothing happens. So, if you wish to see the changes you propose, I'd say your best bet is to start *doing* something about it (besides talking about it on the forum, that is). Remember that this is an open source project with contributions made by volunteers; telling volunteers what to do with their free time rarely works. Contributing real work, OTOH, tends to catch people's attention much more effectively. T -- The most powerful one-line C program: #include "/dev/tty" -- IOCCC
Nov 27 2014
next sibling parent reply "Vic" <vic.cvc gmx.com> writes:
I completely understand and support the DIY nature of Open Source 
and it's something that should be underlined often!

If we turn out to be successful, I  do plan to resource out D 
support. But I'm running a startup and don't have the spare 
cycles. But I am using D, betting the company on it, programmers 
in my shop do D 100% of time, so I do consider myself a part of 
the D community.
So all I can do is wish for a small and stable D lang, vs a large 
D experimental platform - and both are possible. If I had 
resources I would divide Phobos and complier/pre-compiler to 
support the 2 camps: people that use D on real projects and 
people that want to experiment as I have outlined.
I do think this to be key thing for the active D community to 
internalize as it relates to D wide adoption or disappearing: the 
size of project managed as it releases to FTE (~2000 hrs/year) 
resources that maintain it. Manifested mostly as 
http://en.wikipedia.org/wiki/Feature_creep or instability (is my 
code wrong or is it D )


On Thursday, 27 November 2014 at 23:24:59 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 On Thu, Nov 27, 2014 at 10:58:31PM +0000, Vic via Digitalmars-d 
 wrote:
 There are 2 users I see, those that see it as an experimental 
 feature
 platform and those that use it for real projects (and not for
 experiments).
[...] The thing is, based on my observations over the past few years or so I've been here, such grand plans have often been proposed (in the best of intentions, to be sure) but rarely carried out. The thing about D is that if you wish to see something happen, you just have to dig in and *do* something about it. Be the champion of whatever you propose, get on the ground and work it out, make it happen. Contribute code. Help improve the infrastructure. Be the change you wish to see take place. While these forums can be quite entertaining, from my observations most of the animated discourse ultimately results in nothing -- because nobody actually got up to *do* something about it. The stuff that *does* happen often happens in the background where somebody actually did the hard work and wrote the code, pushed the PR's through to acceptance, contributed the hardware to improve the infrastructure, etc., often with little or no activity on the forums. Almost all of the discussions on the forums that have little or no code backing it up tend to just sputter out after everyone's energy has been exhausted, and nothing happens. So, if you wish to see the changes you propose, I'd say your best bet is to start *doing* something about it (besides talking about it on the forum, that is). Remember that this is an open source project with contributions made by volunteers; telling volunteers what to do with their free time rarely works. Contributing real work, OTOH, tends to catch people's attention much more effectively. T
Nov 27 2014
parent "Mike" <none none.com> writes:
On Friday, 28 November 2014 at 00:17:19 UTC, Vic wrote:

 So all I can do is wish for a small and stable D lang, vs a 
 large D experimental platform - and both are possible. If I had 
 resources I would divide Phobos and complier/pre-compiler to 
 support the 2 camps: people that use D on real projects and 
 people that want to experiment as I have outlined.
You are not leveraging all of phobos or druntime, right? What is the minimal amount of D that you need? With that scope in mind, you may find that it would require minimal resources in time or funds to fix the issues that you are encountering. Again, without knowing what those issues are, no one can say. Mike
Nov 27 2014
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 27 November 2014 at 23:24:59 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 *do* something about it. Be the champion of whatever you 
 propose, get on
 the ground and work it out, make it happen. Contribute code. 
 Help
 improve the infrastructure. Be the change you wish to see take 
 place.
Sound advice if you want a single feature, but this does not work for restructuring and management. You cannot "commit" people into moving in the same direction, you need to create common ground. That takes time if there is no skilled leader to pull it through.
 While these forums can be quite entertaining, from my 
 observations most
 of the animated discourse ultimately results in nothing -- 
 because
 nobody actually got up to *do* something about it.
I disagree, intelligent people pick up the arguments even though they may not like them at the time they face them. These arguments eventually move up through their brainstem if they are good at learning (I think most programmers are good at that). By iterating over the most problematic issues you get many viewpoints and a new direction might emerge over time (measured in years, not weeks). The nogc focus got in by "external" advocacy. It did take some noise, but it got in.
 So, if you wish to see the changes you propose, I'd say your 
 best bet is
 to start *doing* something about it
In this case it actually means refactoring the compiler codebase, which will by necessity lead to a fork if this is not wanted by the main developers as it will break up their existing mental model of the program.
Nov 27 2014
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Friday, 28 November 2014 at 00:19:49 UTC, Ola Fosheim Grøstad
wrote:
 The  nogc focus got in by "external" advocacy. It did take some 
 noise, but it got in.
It took a lot of noise and IMO rust removing their GC to force something to happen.
Nov 27 2014
parent "Vic" <vic.cvc gmx.com> writes:
Yes, that is one example of something that could be a downstream 
feature with alternative implementations.

On Friday, 28 November 2014 at 01:29:16 UTC, weaselcat wrote:
 On Friday, 28 November 2014 at 00:19:49 UTC, Ola Fosheim Grøstad
 wrote:
 The  nogc focus got in by "external" advocacy. It did take 
 some noise, but it got in.
It took a lot of noise and IMO rust removing their GC to force something to happen.
Nov 28 2014
prev sibling next sibling parent "weaselcat" <weaselcat gmail.com> writes:
Isn't this the purpose of std.experimental?
Nov 27 2014
prev sibling next sibling parent reply "Mike" <none none.com> writes:
On Thursday, 27 November 2014 at 22:58:33 UTC, Vic wrote:

 The 'real project/core' is where we are ( 
 http://blog.apakau.com/2014/11/cmg-paper ) and we need a stable 
 systems language. From 'real project' people, the people that 
 are in the 'experimental platform' currently *shit* where we 
 eat (as per my D programmers that work for me, D is big and 
 unstable).
Can you be more specific about the instability you are encountering? Are you referring to the changes between releases, or problems due to bugs? And which changes/bugs have you encountered that have cause you grief?
 If you are w/ me so far, how big/small should core be?
 *Small enough to be maintained by the size of the team at hand 
 and no larger. *
As I see it, D has a lot of contributors willing to maintain and enhance it, but the barrier to entry and learning curve is quite high for anything significant. Therefore, the number of contributors that actually make a significant difference is quite small. Also, since it is a volunteer effort, there's really not much accountability. Contributors are free to make significant contributions, and then leave the D scene without anyone able to maintain their work. Contributors are also free to do partial implementations, and move onto something else without completing what they started. I think anyone wishing to leverage D for a critical project should be aware of that, and perhaps D should be more transparent about it. That doesn't mean D shouldn't be used for anything of importance, it just means that by using D we enter into an implicit contract requiring us to either be willing to become significant contributors ourselves, or be willing to partner with and fund D's development. When I first approached D, I had high expectations, and as I learned more, I also became disappointed and said a few things I this forum I wish I could take back. I misunderstood the culture of this community and how it works, and perhaps I still do. But what is more apparent now is we can't expect to rely on D if we're not willing to make significant contributions ourselves, or fund its development. And, while using D is itself a small contribution, it's not enough.
 Lets make D core small please. List of things that are core: 
 char arrays.  What else should be core?
 The key question in this tread: how small should core D be to 
 be maintainable and stable? How can it be split?
I would like D core to be small as well, but for different reasons: I would like a nimble language that can be used for both the smallest and largest of machines, and let the libraries differentiate. But, I don't think it should be partitioned based on the size of D's human resources, partially because that is going to fluctuate drastically throughout time. Rather, the division should be made based on architectural and design goals. You might consider doing what other organizations have done: Allocating your D talent to fix the problems you have encountered by submitting pull requests, or open issues and place bounties on them at https://www.bountysource.com/teams/d/issues. Regardless, I'd still be interested in knowing, more specifically, what problems you're encountering. Mike
Nov 27 2014
parent reply "Vic" <vic.cvc gmx.com> writes:
inline:

On Friday, 28 November 2014 at 05:14:31 UTC, Mike wrote:<snip
 As I see it, D has a lot of contributors willing to maintain 
 and enhance it, but the barrier to entry and learning curve is 
 quite high for anything significant.
I say there is very few. I have to challenge your data that there is a lot of contributors. Most projects list their maintainers, what is the number of FTE D maintainers? That is a loaded question of course, relative to surface area: http://dlang.org/comparison.html of sacred cows relative to FTE maintainers.
 Therefore, the number of contributors that actually make a 
 significant difference is quite small.
 Also, since it is a volunteer effort, there's really not much 
 accountability.  Contributors are free to make significant 
 contributions, and then leave the D scene without anyone able 
 to maintain their work.  Contributors are also free to do 
 partial implementations, and move onto something else without 
 completing what they started.

 I think anyone wishing to leverage D for a critical project 
 should be aware of that, and perhaps D should be more 
 transparent about it.  That doesn't mean D shouldn't be used 
 for anything of importance, it just means that by using D we 
 enter into an implicit contract requiring us to either be 
 willing to become significant contributors ourselves, or be 
 willing to partner with and fund D's development.
How much $ funding so I consider it? For example for regressions to be done but only for core. (none of silly things, which is a long list of GC, AssociaveArrays, demangle, annotations, higher order functions, pseudo members, transmogrify, goto, try/catch, vardic, traits, variant, sqllite, etc. I am not saying to remove them, just make them downstream like GNU does, not part of regression tested D core. If I wanted to use a big lang I'd do CLR or JRE.
 When I first approached D, I had high expectations, and as I 
 learned more, I also became disappointed
Yes, that is the pattern. Come in, and leave. There has to be more people staying and more D shops (like my shop is pure 100% D ). The regressions are painful, and I propose a way to let people experiment and compete on rich features. My proposal is to make a small stable core that can be maintained, so that people say.
 and said a few things I this forum I wish I could take back.  I 
 misunderstood the culture of this community and how it works, 
 and perhaps I still do.  But what is more apparent now is we 
 can't expect to rely on D if we're not willing to make 
 significant contributions ourselves, or fund its development.  
 And, while using D is itself a small contribution, it's not 
 enough.

 Lets make D core small please. List of things that are core: 
 char arrays.  What else should be core?
 The key question in this tread: how small should core D be to 
 be maintainable and stable? How can it be split?
I would like D core to be small as well, but for different reasons: I would like a nimble language that can be used for both the smallest and largest of machines, and let the libraries differentiate. But, I don't think it should be partitioned based on the size of D's human resources, partially because that is going to fluctuate drastically throughout time. Rather, the division should be made based on architectural and design goals.
The culture of the D contributes is 'to bravely peer into gates of hell' - as in experiment. As user of D I want it to be small, stable and maintained. I proposed a path that allows for both, w/o scaring of people that use D for real projects. If that is not so, then I missed that D is an experimental language.
 You might consider doing what other organizations have done:  
 Allocating your D talent to fix the problems you have 
 encountered by submitting pull requests, or open issues and 
 place bounties on them at 
 https://www.bountysource.com/teams/d/issues.

 Regardless, I'd still be interested in knowing, more 
 specifically, what problems you're encountering.

 Mike
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). I told them: we are a D shop because long term I anticipate D and Walter to succeed. So I hope that maintainers consider users of D and not chase them away. Vic
Nov 28 2014
next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 28 Nov 2014 20:00:35 +0000
Vic via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 etc. I am not saying to remove them, just make them downstream=20
 like GNU does, not part of regression tested D core.  If I wanted=20
 to use a big lang I'd do CLR or JRE.
if i wanted some crippled language that has almost nothing in it, i can take any of the scripting languages out here, or some esoteric compiler. having dynamic arrays, associative arrays and strings in the language is a must for me: i don't want to reinvent the wheel each time or add some libraries for such simple things (yes, C, i'm talking about you!). and having alot of things in phobos is great too: i still don't have to download another library for levenstein distance, for example (yes, i really used that and was very happy to find it right into std.algorithm). and i really enjoyed the fact that all this is a part of the language that undergoes testing on par with basic features.
 When I first approached D, I had high expectations, and as I=20
 learned more, I also became disappointed
=20 Yes, that is the pattern. Come in, and leave. There has to be=20 more people staying and more D shops (like my shop is pure 100% D=20 ). The regressions are painful, and I propose a way to let people=20 experiment and compete on rich features. My proposal is to make a=20 small stable core that can be maintained, so that people say.
you can fork and experiment as you want. my private build of DMD has more than 100KB of patches applied at build time, for example.
 My problem: I have 3 developers(still hiring more) that work for=20
 me please lets not use D, it is not stable release to release=20
 (and has a bunch of things no one needs).
this has an easy solution: just stick with the chosen D version: nobody forces anyone to upgrade. even more: we have dfix now, which will help to make upgrade process alot less painfull.
Nov 28 2014
parent reply "Mike" <none none.com> writes:
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.
Nov 28 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Nov 28, 2014 at 11:06:14PM +0000, Mike via Digitalmars-d 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.
Yeah, it's not wise to keep upgrading the compiler, even in C/C++, since many enterprise products tend to exhibit subtle breakages with new compilers. (You may have heard of Linus ranting about newer versions of GCC that "miscompile" the kernel, for example -- I remember back in the day, the word was that you had to use egcs to compile the kernel, otherwise if you get a kernel panic you're on your own, the devs can't (and won't) help you). The code that I work on in my day job has a lot of compiler-specific hacks, and would *certainly* become unusable if we were to build it with a non-standard compiler -- standard being what's shipped in the development environment that we are required to use for building it, which hasn't changed for the last 5 years at least (so it's definitely *not* a new compiler!). Of course, being stuck with an obsolete version of D is Not Nice, so one idea that occurs to me is to do infrequent, preplanned upgrades. For example, say you standardize on dmd 2.066 for the current product release. This means that you will *only* compile with 2.066 and nothing else, and developers are required to use only the "official" compiler version for their work. This also means that you, being the boss, decide what feature sets are / aren't allowed in your codebase. For example, glancing over Google's C++ style guide, many C++11 features are banned outright -- even though ostensibly they must have *some* value to *somebody*, otherwise they wouldn't be in the spec! So basically, you decide on the compiler version and feature set, and stick with that. Now, the product may take a long time to develop, ship, and maintain, so by the time it's in maintenance mode, it could be several years from now. By then, upstream dmd may already be at 2.074, say, but your codebase is still only 2.066. At some point, you'll want to upgrade -- but that should be done wisely. Never ever upgrade your mainline development wholesale -- if you run into problems (e.g., a language feature you depended on has changed and it's non-trivial to update the code to work around it) you don't want to find yourself in the unpleasant position of having a non-working codebase. Instead, start out a pilot branch with one or two dedicated developers who will (attempt to) build the code with the latest compiler. If you're extremely, extremely, extreeeeeemely lucky, all goes well and you can run some unittests, then some controlled field testing, then switch over. More likely, though, you'll run into some issues -- compiler bugs that got fixed and code that relied on that is now broken, etc.. So you take the time to investigate -- on the pilot branch -- how to work around it. Once everything is figured out, start investing more effort into porting the codebase over to the new compiler -- at the same time evaluating possible new feature sets to include in your list of permitted features -- while still keeping the 2.066 compiler and the original branch around. Don't ever throw out the old compiler until the older product release is no longer supported. Ideally, the new branch will coincide with the next major release of your product, which should give you some time to sort out compiler bugs (new and old), language workarounds, etc.. Once the new release is stabilized enough to be shippable, you can start deprecating the older codebase and eventually drop it. Basically, this isn't too much different from what you'd do with any other 3rd party product that you depend on -- you never just drop in a new 3rd party release with no planning and no migration path, that's just asking for trouble. You always keep the current environment running until the new one has been proven to be stable enough to use, then you switch over. T -- "Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next. -- (Stolen from the net)
Nov 28 2014
next sibling parent "Mike" <none none.com> writes:
On Friday, 28 November 2014 at 23:38:40 UTC, H. S. Teoh via 
Digitalmars-d wrote:

 Of course, being stuck with an obsolete version of D is Not 
 Nice, so one
 idea that occurs to me is to do infrequent, preplanned upgrades.
Yes, the important word there is "preplanned". We still use Visual Studio 6.0 (1998) for some of our products. I spent the last month working in Visual Studio 2008. Mike
Nov 28 2014
prev sibling parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Friday, 28 November 2014 at 23:38:40 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 For example, say you standardize on dmd 2.066 for the current 
 product release. This means that you will *only* compile with 
 2.066 and nothing else, and developers are required to use only 
 the "official" compiler version for their work.  This also 
 means that you, being the boss, decide what feature sets are / 
 aren't allowed in your codebase. For example, glancing over 
 Google's C++ style guide, many C++11 features are banned 
 outright -- even though ostensibly they must have *some* value 
 to *somebody*, otherwise they wouldn't be in the spec! So 
 basically, you decide on the compiler version and feature set, 
 and stick with that.

 Now, the product may take a long time to develop, ship, and  
 maintain, so
 by the time it's in maintenance mode, it could be several years 
 from now. By then, upstream dmd may already be at 2.074, say, 
 but your codebase is still only 2.066. At some point, you'll 
 want to upgrade -- but that should be done wisely.

 Never ever upgrade your mainline development wholesale -- if  
 you run
 into problems (e.g., a language feature you depended on has 
 changed and it's non-trivial to update the code to work around 
 it) you don't want to find yourself in the unpleasant position 
 of having a non-working
 codebase. Instead, start out a pilot branch with one or two 
 dedicated developers who will (attempt to) build the code with 
 the latest
 compiler. If you're extremely, extremely, extreeeeeemely lucky, 
 all goes well and you can run some unittests, then some 
 controlled field testing,
 then switch over.

 More likely, though, you'll run into some issues -- compiler 
 bugs that got fixed and code that relied on that is now broken, 
 etc.. So you take the time to investigate -- on the pilot 
 branch -- how to work around it.
 Once everything is figured out, start investing more effort 
 into porting the codebase over to the new compiler -- at the 
 same time evaluating possible new feature sets to include in 
 your list of permitted  features
 -- while still keeping the 2.066 compiler and the original 
 branch around. Don't ever throw out the old compiler until the 
 older product release is no longer supported. Ideally, the new 
 branch will coincide with the next major release of your 
 product, which should give you some time to sort out compiler 
 bugs (new and old), language workarounds, etc.. Once the new 
 release is stabilized enough to be shippable, you can start 
 deprecating the older codebase and eventually drop it.

 T
Well said. I don't know any "sane" software company not being ruled by a process like that. Here in SRLabs we are sticking with what you have described, with one variation: one person (and only one), it's constantly trying to build a branches of the projects with the latest compiler, testing our internal pull requests. Many bugs are avoided, as detected by more recent compiler version, and it's very rare not being able to keep the pace with the other developers. From time to time, during the development of some product, we are so confident by the state of the "unstable" to just jump everyone to a more recent compiler version. But when the product is released, we stick with the version of the compiler used to release it, till it's end-of-life. --- Paolo
Nov 29 2014
prev sibling parent reply "Vic" <vic.cvc gmx.com> writes:
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
Nov 29 2014
parent "Jarrett Tierney" <serates gmail.com> writes:
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
Dec 01 2014
prev sibling next sibling parent "Mike" <none none.com> writes:
On Friday, 28 November 2014 at 20:00:36 UTC, Vic wrote:
  I say there is very few.  I have to challenge your data that 
 there is a lot of contributors. Most projects list their 
 maintainers, what is the number of FTE D maintainers?
You can see the lists here: https://github.com/D-Programming-Language/dlang.org/graphs/contributors https://github.com/D-Programming-Language/dmd/graphs/contributors https://github.com/D-Programming-Language/druntime/graphs/contributors https://github.com/D-Programming-Language/phobos/graphs/contributors There's not going to be a high FTE count because D is a volunteer effort with, from what I can tell, no significant financial support. This is not a secret and users should be aware of this when they choose to use D. As I said in my previous post, IMO, users should expect to either contribute programming talent or funds if they intend to use it for anything critical.
 How much $ funding so I consider it?
 For example for regressions to be done but only for core. (none 
 of silly things, which is a long list of GC, AssociaveArrays, 
 demangle, annotations, higher order functions, pseudo members, 
 transmogrify, goto, try/catch, vardic, traits, variant, 
 sqllite, etc. I am not saying to remove them, just make them 
 downstream like GNU does, not part of regression tested D core.
  If I wanted to use a big lang I'd do CLR or JRE.
Can't the features that you don't need just be ignored? The .Net Framework is HUGE, but that doesn't prevent me from using a very small subset of it for my work.
 The regressions are painful, and I propose a way to let people 
 experiment and compete on rich features. My proposal is to make 
 a small stable core that can be maintained, so that people say.
Do you have a bugzilla issue for each of the regressions you're referring to? The regressions that I see listed here (http://wiki.dlang.org/Beta_Testing#Available_Downloads) are quite small in number, and arguably in code that is rarely employed.
 The culture of the D contributes is 'to bravely peer into gates 
 of hell' - as in experiment. As user of D I want it to be 
 small, stable and maintained. I proposed a path that allows for 
 both, w/o scaring of people that use D for real projects. If 
 that is not so, then I missed that D is an experimental 
 language.
I don't see D as an experimental language. "Experimental" implies it's trying features that may or may not work, and is trying to see how they pan out. From what I can tell, the vast majority of D's features are borrowed from other time-tested, proven languages, and the D specific features that I've employed have been powerful and liberating.
 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).
1) Not stable release-to-release? Which regressions? Please provide links to the bug reports. Without these, there's nothing actionable, and you're argument against D is questionable. Ask your developers for something specific and actionable. You may be pleasantly surprised by the helpfulness of this community...or not. 2) has a bunch of things no one needs... The things you don't need don't need to be employed. This seems to be your fundamental premise: Because D is a feature rich language with limited resources, resources are spread too thin making D unmaintainable with the resources it has. I'm not convinced. First of all, that doesn't appear to be how this effort works. There isn't a CEO setting priorities and cracking a whip over contributors' heads. Contributors largely work on those things that interest them. Second, if D were to move non-core features downstream, the contributors that work on those features will also move downstream, thinning D's core resources even further. If regressions are the problem, please file bug reports and bring them to this community's attention. You may find some helpful people willing to address them for free simply because it interests them or it was something they were meaning to get to, and just needed a little motivation. If there isn't anyone willing to address them, the problem could potentially be monetized. Mike
Nov 28 2014
prev sibling next sibling parent reply "Elie Morisse" <syniurge gmail.com> writes:
On Friday, 28 November 2014 at 20:00:36 UTC, Vic wrote:
 (...)
IMHO you should be ready to debug the compiler. DMD's codebase can be obscure at times (while the LDC mid-end is pretty straightforward) so the first time looking for the source of a bug may be a frustrating and time-consuming learning experience, but you'll be empowered to tackle compiler bugs without relying on volunteers to do it for you, and without stopping D from evolving.
Nov 29 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 29 November 2014 at 15:37:12 UTC, Elie Morisse wrote:
 IMHO you should be ready to debug the compiler.

 DMD's codebase can be obscure at times (while the LDC mid-end 
 is pretty straightforward) so the first time looking for the 
 source of a bug may be a frustrating and time-consuming 
 learning experience, but you'll be empowered to tackle compiler 
 bugs without relying on volunteers to do it for you, and 
 without stopping D from evolving.
If this is a long term strategy then this makes D unsuitable for contract work. You really don't want any uncertain factors when bidding on a contract since that will skew your estimates. Stability is more important than features in a commercial setting.
Nov 29 2014
parent "Vic" <vic.cvc gmx.com> writes:
On Saturday, 29 November 2014 at 15:46:03 UTC, Ola Fosheim 
Grøstad wrote:
<snip>
 If this is a long term strategy then this makes D unsuitable 
 for contract work. You really don't want any uncertain factors 
 when bidding on a contract since that will skew your estimates. 
 Stability is more important than features in a commercial 
 setting.
yes
Nov 29 2014
prev sibling parent "Kagamin" <spam here.lot> writes:
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?
Dec 03 2014
prev sibling next sibling parent "Joakim" <dlang joakim.fea.st> writes:
On Thursday, 27 November 2014 at 22:58:33 UTC, Vic wrote:
 There are 2 users I see, those that see it as an experimental 
 feature platform and those that use it for real projects (and 
 not for experiments).

 The 'real project/core' is where we are ( 
 http://blog.apakau.com/2014/11/cmg-paper ) and we need a stable 
 systems language. From 'real project' people, the people that 
 are in the 'experimental platform' currently *shit* where we 
 eat (as per my D programmers that work for me, D is big and 
 unstable).
 As I see it, the issue is that D is a wide platform(not a small 
 lang)  that is hard to maintain with the size of the team. 
 (Similar wide platforms feature wise are JRE and CLR, both w/ > 
 100 developers). So how many core D developers we have?(*)

 A more modern language like Go splits btwn stable 'core' and 
 'experimental feature platform', for example no need for core 
 to have try/catch, when it can be done downstream:
  - http://github.com/manucorporat/try
 This is similar to Linux: kernel and gnu; and what I propose 
 for D: to be split up.

 This would allow users of *real project* to use a core and 
 people that want to have  features could do that downstream: 
 let a 1000 flowers bloom!

 If you are w/ me so far, how big/small should core be?
 *Small enough to be maintained by the size of the team at hand 
 and no larger. *

 Something stable for us to lean on.
 Next, is it feasible to split? Std library has much bloat and 
 is easy to split up into core and downstream experimental 
 feature platform.
 That leave the compiler. I am not an expert, but this could be 
 done w/ core 'compiler' and the rest in optional pre-processor. 
 I think it can be done w/ backwards compatible (just switch GC 
 to default off)

 I'll say 90% +  should and must be moved to downstream 
 projects. This allows for the famous quote: 'fearlessly peer 
 into the gates of hell’ - all I’m saying do it downstream, let 
 us build projects that can lean on small/simple and 
 maintainable D core.

 Lets make D core small please. List of things that are core: 
 char arrays.  What else should be core?
 The key question in this tread: how small should core D be to 
 be maintainable and stable? How can it be split?

 http://tinyurl.com/q5t2eag
While all this may be true, why does the code base need to be split for you to use the core, ie can't you just stay away from new and experimental features of the language? Perhaps you don't know the age or level of stability of each feature, but it strikes me that starting a project to document that would be much easier than trying to push a split.
Nov 28 2014
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
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?
Dec 03 2014
prev sibling next sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
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.
Dec 03 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Dec 03 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Dec 03 2014
prev sibling parent "Dicebot" <public dicebot.lv> writes:
It is all solved by semver and release discipline - something 
language authors are strongly against.
Dec 04 2014