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

[Joakim via Digitalmars-d]

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.