Opportunities for D

[via Digitalmars-d]

On Thursday, 10 July 2014 at 14:30:38 UTC, Andrei Alexandrescu 
wrote:
> In the meantime, everybody's busy arguing the minutia of logo 
> redesign. The length (not existence) of that thread is a piece 
> of evidence of what's wrong with our community.

Actually, that thread is a good sign and a good source for 
community building. You know, people establishing boundaries and 
goals together rather than trying to figure out if it is worth 
contributing the vision of somebody else or adding to an existing 
patchwork which has a unclear direction. It was a small managable 
piece (the logo) so people felt like participating. It also was a 
ground where people can share their views on 
what-we-really-are-about on an abstract level.

> Of course that doesn't undo the fact that Walter and I are on 
> hook for a number of things. What I'm saying is I disagree with 
> the allegation that "no amount of volunteer effort will help". 
> From the looks of things, we're in dire need of volunteer 
> effort.

Motivation is a difficult sport, but it would help a lot if you 
just specced out the D2 language fully and plotted in the missing 
parts, without implementation, but with proofs of correctness. 
All this putting stuff in, then ripping it out is demotivating. 
(Why contribute if it will be ripped out at the next turn of 
events?)

People with formal training (CS background) will favour elegance 
and correctness, which implies solid advance speccing… Without 
it, they are unlikely to contribute unless they have D in 
production or miss features which could make it possible for them 
to use D in production…

There is too much pushing for breadth in the D community. What 
you need is depth, the depth of quality and polish. Possibly 
reducing the scopes and feature set, not extending it even more.

Maybe you have to cut back on system programming and go for fast 
brute force lock-the-world GC without destructors, or maybe you 
have to favour system programming. But surely, the worst option 
is to not set a clear direction.

To match up with the best-in-class in the web space you need a 
tight performant HTTP and SPDY implementation with support for 
all relevant content negotiation headers, solid caching handling, 
automatic compression, well working timeouts/load balancing, all 
the right hooks for rapid development, builtin Memcache support, 
a solid NOSQL abstraction, a transactional task queue and be 
tight on memory so you can run the service on cheap hosting. That 
would bring you to the basics of Go/App Engine… Then you have to 
be better…

Kudos for vibe.d, but it won't really matter until it is better 
than the alternatives. Building WordPress on top of it won't 
matter, because creating WordPress is not difficult. The 
difficult part is building the WordPress community.