Maybe D is right about GC after all !

[Joakim]

On Wednesday, 27 December 2017 at 18:13:41 UTC, Russel Winder 
wrote:
> The challenger has to offer something that the community value. 
> Rust offers memory safety over C. D offers "better C++". This 
> is the wrong message to achieve traction. D must offer 
> something that C++ does not offer.

If you're a better version of one of the market leaders, that's 
good enough.  If you were just a better Erlang, that'd be a 
marketing problem!

> But as of 2017-03-30 I have no hidden agenda, i.e. I retired. 
> :-) This mjeans I am just doing what I want, which currently is 
> organising ACCU conference, organising DevoxxUK conferences and 
> programming DVB-T and DAB clients. D has failed to get traction 
> at ACCU, has no chance at all at DevoxxUK, and has lost to Rust 
> in DVB-T and DAB applications.

So D is invisible in the places you frequent, but has anybody 
written an entire storage system in Rust?

https://www.theregister.co.uk/2017/12/22/a_dive_into_wekaios_parallel_file_system_tech/

My point is that D and Rust are both currently lower-traction 
languages, so it's expected that you don't find them in many 
places.  Rust is certainly doing better right now, because it is 
focused on the niche of memory safety, but that means Gerald 
almost certainly isn't going to use it for his Gtk-based tiling 
terminal emulator:

https://dlang.org/blog/2017/08/11/on-tilix-and-d-an-interview-with-gerald-nunn/

D and Rust are going after different markets, but D is trying to 
stay more general-purpose, which Rust has abandoned so far 
(though their upcoming GC may be a step towards more general use).

On Wednesday, 27 December 2017 at 18:41:41 UTC, Laeeth Isharc 
wrote:
> That's really the whole point about D.  It's an era where 
> people start out assuming that using the right tool for the job 
> means that one tool can't do two different kinds of job well.  
> But, as Walter has said elsewhere I think, in some cases that's 
> because the tools people are used to using are limited, whereas 
> in fact there's no need for that - just use one tool that's 
> good at both.
>  It's going to be a struggle to recognise such a tool if you 
> start with the presumption it cannot exist.

This reminded me of a current theme in tech, the tension between 
modularity and integration.  Here's an example quote from a 
couple months ago:

"But the long arc of history shows how hard it is to succeed in 
vertical integration after you build on horizontal foundations. 
Generations of managers graduated from the modular school of 
thought, specializing rather than generalizing. Now they are 
facing an integrated experiential world where progress depends on 
wrapping the mind around very broad systems problems."
http://www.asymco.com/2017/10/04/orthogonal-pivots/

The canonical example is how Apple doesn't compete on 
feature/spec checklists but on an integrated experience that just 
works better.  That may be tougher to market for tech users, but 
it is increasingly what people want, even many programmers.