What is the D plan's to become a used language?

[Vic via Digitalmars-d]

First, thank you all the committers for a 'gifted free' lang that 
we use to build a company, we could have used any lang, we chose 
D.

My point is on 'management' more than on 'software'. On 
management, *EVERY* project is resource constrained, so imo, D 
should figure out what resources it has at hand. Based on that 
prioritize what can be maintained and what can't be maintained 
and hence marked as deprecated (so those that do care for it can 
move it downstream). It's painful to kill many scared cows. I 
used example or CLR and JRE team size relative to their 'features 
surface area'.

Also, I'm pleased that 'no' is said at times (but ... we are 
still adding things right, w/o saying: and if we add that, what 
are 2 features we can move downstream?'. Last I'm hearing is 
Andreii will gift C++ compatibility, etc into core. **: reason to 
split up forum into users and public comitters so people like me 
don't panic)
Cheers,
Vic
ps:
Second smaller thing I 'elude' to but don't verbalize in that 
argument is my personal preference for a smaller language. Less 
is better/faster. I proposed to move those deprecated  features 
'downstream', just like Linux Kernel and Linux GNU are separated 
(but can't exist w/o each other). To build an eco system.
(here is comments on C++ having more features, one of the reasons 
I like smaller
http://harmful.cat-v.org/software/c++/linus
I do see 'featuritis' http://bit.ly/1wzVPMR as a way to doom 
projects in a compound way )

As to Walter (yes I used Wacom c compiler) saying No, I think he 
is to nice and 99.5% is not good enough, I'd like him to be a mean
- http://www.brainyquote.com/quotes/quotes/l/linustorva141511.html
and start removing things. The list of candidates is long, GC has 
been brought up as something that can be moved downstream.
D could have reference counters in base classes, but end users 
could INJECT a 3rd party GC mechanism they like. It's same thing, 
but downstream. Also I showed example of Go exceptions being 
downstream.
I'm not saying these 2 (our of 100) are not nice features, I'm 
saying if 'we' were forced, they could be moved downstream. You 
can just open Andreii's D book table of contents and find over 
weight things - if you are motivated to do that.


On Friday, 19 December 2014 at 16:44:59 UTC, Joakim wrote:
> On Friday, 19 December 2014 at 15:11:30 UTC, Tobias Pankrath 
> wrote:
>> On Friday, 19 December 2014 at 14:58:07 UTC, Joakim wrote:
>>> On Friday, 19 December 2014 at 14:38:02 UTC, Tobias Pankrath 
>>> wrote:
>>>>> As for Walter already saying "no" a lot, given how many 
>>>>> features D has, obviously one can still wish he went from 
>>>>> 99% "no" to 99.5%. ;)  You don't need to be around the D 
>>>>> community forever to feel that D still has too many 
>>>>> features that made it in.
>>>>
>>>> Care to name a few and justify why exactly those features 
>>>> should be gone?
>>>
>>> No, as that's not really my problem.  I was simply trying to 
>>> clarify the argument others have made, that the language 
>>> seems overstuffed and overwhelming, which I have experienced 
>>> at times but I'm not personally complaining about.>
>>
>> It is a worthless claim to make that there is too much of 
>> something, if you cannot come up with an concrete example. 
>> "I've got that gut feeling, that" is not even remotely an 
>> argument and just kills time of everyone in this discussion.
>>
>> If we want to discuss the future of the language, it's totally 
>> pointless to do it in an abstract way. “We need to make the 
>> language more stable“ is not a goal or something, it is 
>> totally unclear what that actually means, why this is 
>> important in the first place, how we can say that we have 
>> accomplished it or what we need to do to realise that goal.
>
> I have no dog in this fight.  I was merely pointing out to 
> Walter and Mike that it's possible to say "no" a lot and still 
> have others wish you had said "no" even more. :) There's no 
> particular feature that I wish wasn't there, though of course 
> there are many features that many wish were implemented or 
> worked together better, as deadalnix points out.
>
> When Vic suggested a split into a stable core and an 
> experimental layer, I suggested documenting the perceived 
> stability of various features instead, so that users could have 
> a guide for what features might be more problematic without 
> having to do a deep-dive in bugzilla to figure it out for 
> themselves.  I didn't back a split or have not suggested 
> removing features.