More radical ideas about gc and reference counting

[Andrei Alexandrescu via Digitalmars-d]

On 5/3/14, 8:48 PM, Caligo via Digitalmars-d wrote:
> On Sat, May 3, 2014 at 3:49 AM, Benjamin Thaut via Digitalmars-d
> <digitalmars-d at puremagic.com <mailto:digitalmars-d at puremagic.com>> wrote:
>
>     2) Quit D. (which is becomeing more and more an option when reading
>     the recent news group discussions.)
>
>     --
>     Kind Regards
>     Benjamin Thaut
>
>
> I never thought I would say this, but I have begun to move away from D.
>   I know others who are doing the same.  The advantages D has over other
> languages are slowly diminishing.  Plus, as it is, D is just as complex
> and complicated as C++, if not more.  Couple that with the never-ending
> bugs and weak development process, there isn't much confidence in
> choosing D.
>
> One of the main and crippling issues D has is its development process.
>   Its inner circle, mainly Walter, Andrei and a few others, do not seem
> to have a good understanding of FOSS development process.  For example,
> Rust is only a few years old and much younger than D, but it has a
> greater number of contributors, and its rate of contributors seems to be
> growing faster.  D has failed at recruitment; I always read people
> (mainly the inner circle) mention the everlasting low-hanging fruits.
>   Well, if the number of contributors was growing then the number of
> low-hanging fruits would be decreasing.  Andrei recently introduced the
> bounty system, which not only is an insult to those who contribute to
> FOSS, but it also goes to show that he really doesn't understand how and
> why people contribute to FOSS without ever asking to be compensated.

Mostly good points, but the bountysource program is an experiment by 
Facebook, not by myself. And (without me trying to speak on Facebook's 
behalf) it would be difficult to argue that Facebook doesn't understand 
FOSS or is out there to insult contributors. We're just experimenting 
with various angles.

> Last but not least, currently there are two main ways for new features
> to make it into D/Phobos: you either have to belong to the inner circle,
> or have to represent some corporation that's doing something with D.  I
> don't remember seeing a feature that was added to D/Phobos with some
> on/off switch that people could try in the next release, and then send
> in feedback.  You're in a much better position to make a decision about
> a feature if the users have actually used it and reported feedback.

The on/off switch may be a nice idea in the abstract but is hardly the 
perfect recipe to good language feature development; otherwise everybody 
would be using it, and there's not overwhelming evidence to that. (I do 
know it's been done a few times, such as the (in)famous "new scoping 
rule of the for statement" for C++ which has been introduced as an 
option by VC++.)

I wonder how you've gotten the perception that one needs to be a member 
of the inner circle mafia to get things into D. Today's major 
contributors to D came from all over, without any preexisting 
relationship to anyone else, and their admission ticket has been getting 
work done. Could you please get into detail on how you view things? (I 
tried to look over your past posts to see a pattern of rejected 
contributions, but didn't find such.)

>   Ahh, and don't get me started on Phobos review process; it's a joke,
> it's bogus and just pathetic.

Actually I'd love to get you started so I'd understand your angle 
better. I'm sure we can do a lot better. One good thing Phobos reviews 
have done since we initiated them has been to prevent bad artifacts to 
make it into the library. We'd love to make it better. From what I saw 
witnessing similar processes (C++, Boost, Python, Scala) - they all have 
some sense of awkward self-importance to them upon the first look. I 
think that's the way such things work.

> If D had a sound development process, I don't think we would be having
> the problems that we have today.

I've discussed development process with a number of people who 
participated at such. They mentioned that until you get teams paid to 
work on the respective system (OS, language, framework etc) it all works 
on the basis of people doing things to scratch an itch they have. The 
critical mass is attained when there are enough people to cover a large 
enough itching area :o). If telling people what to work on on their free 
time works, I haven't succeeded at it and don't know anyone who has.


Andrei