Idea #1 on integrating RC with GC

[Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>]

On Tuesday, 11 February 2014 at 17:55:36 UTC, Andrei Alexandrescu 
wrote:
>> better C++. It kinda sticks. Because people really want that.
>
> I don't think so, at all. Anyone working on D must drop the 
> moniker "D is a better C++" like a bad habit, no two ways about 
> that. Most of it does it sets C++ as the benchmark. People who 
> already like C++ would be like "you wish" and people who hate 
> C++ would be like "better crap is not what I need anyway".

(I don't really agree, because whenever I use C++ I feel like 
implementing my own language or recently: take another look at D.)

But for people looking for a system level programming language, 
C++ is a baseline. So you will invariably be measured against it.

If you think in terms of "lost opportunities", I believe D looses 
out by not providing a compiler switch that turns off the GC and 
issues errors whenever GC-dependent constructs are being used. 
Not elegant, but simple and makes it easy to start doing real 
time programming because you then have achieved near parity with 
C++ baseline requirements.

If you have limited resources you need to switch to thinking 
about baselines, key requirements and where you loose your 
audience.

D looses opportunities for growth by not having a stable release 
that is perceived as current.  You could (in theory) make a base 
line release, by focusing on the compiler and the runtime, 
pushing features that are not essential for forward compatibility 
into the next release and only release the aspect of phobos you 
are happy with.

A known current, stable and supported release makes it possible 
to plan for others wanting to use D for production and would open 
up for branches for their own projects, like real-time features.

I believe that by delaying a stable release in order to make it 
feature complete, you loose out, because you move out of the 
planning window (let's say 6-12 months) for those assessing 
possible technologies.

> We want to make D a great language all around, with 
> system-level access and also convenience features.

If you go too hard in the Application Language direction the 
System Level will be less visible. And there is more of a future 
for a system level compiled language with limited tool support.

> It's there in <h2> at the top of our homepage: "Modern 
> convenience. Modeling power. Native efficiency."

Slogans doesn't tell me much, I think we talk past each other 
here.

> By the way, this whole "plop a vision page" thing doesn't seem 
> to be quite popular:

I think Rust's homepage and documentation is clear.

By "vision" I mean that future which the tool will bring with it 
as it appears to the reader. That which brings excitement and 
engagement: "I want that future".

Basically the long term goals. Those that you might not achieve 
in generation 1, 2, 3… but which you are approaching.

What I found exciting about W.B.'s original D1 was those aspects 
where D also would bring along semantics that make it possible to 
optimize better than C/C++, such as whole program optimization. 
It does not have to be in this generation of compilers to be 
communicated as language goals.

Immutability, pure, templates etc are useful, but not exciting. 
And not unique for D.

Anyway, I wish you the best of luck. I look forward to your next 
stable release and hope to be able to adapt the stable runtime to 
real time uses and make it available as patches for those 
interested. A long running development branch is outside my time 
window (e.g. I might have moved on to other things by the time it 
can be expected to reach maturity).

Cheers,
Ola.