D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)

[Ola Fosheim Grøstad]

On Tuesday, 4 September 2018 at 13:34:03 UTC, 
TheSixMillionDollarMan wrote:
> I think D's 'core' problem, is that it's trying to compete 
> with, what are now, widely used, powerful, and well supported 
> languages, with sophisticate ecosystems in place already. 
> C/C++/Java/C# .. just for beginners.

Yes, I believe there was an academic early on that allowed 
students to use D, but when C++17 (etc) came about he held the 
view that it would be better for D to align its semantics with 
C++. He was met with silence, except me, who supported that view. 
D is too much like C++ for a skilled modern C++ programmer to 
switch over, but D semantics are also too different to compile to 
C++ in a useful manner.

> Then it's also trying to compete with startup languages (Go, 
> Rust ....) - and some of those languages have billion dollar 
> organisations behind them, not to mention the talent levels of 
> their *many* designers and contributors.

Ok, so my take on this is that Rust is in the same group as D 
right now,  and I consider it experimental as I am not convinced 
that it is sufficient for effective low level programming. 
Although Rust has more momentum, it depends too much on a single 
entity (with unclear profitability) despite being open sourced, 
just like D. Too much singular ownership. Go is also open source 
in theory, but if we put legalities aside then I think it is 
having the traits of a proprietary language. They are building up 
a solid runtime, and it has massive momentum within services, but 
the language itself is somewhat primitive and messy. Go could be 
a decent compilation target for a high level language.

That said , I think most languages don't compete directly with 
other languages, but compete within specific niches.

Rust: for writing services and command line programs where C++ 
would have been a natural candidate, but for people who want a 
higher level language or dislike C++.

Go: for writing web-services where Python, Java  and C# is 
expected to be too resource-intensive.

D: based on what seems to be recurring themes in the forums D 
seems to be  used by independent programmers (personal taste?) 
and programmers in finance that find interpreted languages too 
slow and aren't willing to adopt C++.

> C++ is much more than just a langauge. It's an established, 
> international treaty on what the language must be.

Yes, it is an ISO-standard, and evolve using a global 
standardisation community as input. As such it evolves with the 
feedback from a wide range of user groups by the nature of the 
process.

> That is not a statement about the quality of D. It's a 
> statement about the competitive nature of programming languages.

It kinda is both, but the issue is really what you aim to be 
supporting and what you do to move in that direction.

When there is no focus on any particular use case, just language 
features, then it becomes very difficult to move and difficult to 
engage people in a way that make them pull in the same direction.

> I wonder has already happened to D.

No, it mostly comes down to a lack of focus and a process to back 
it up. Also, memory management should be the first feature to 
nail down, should come before language semantics...

> I just do not see, how D can even defeat its' major competitors.

But are they really competitors? Is D predominantly used for 
writing web-services? What is D primarily used for? Fast 
scripting-style programming?

> Instead D could be a place where those competitors come to look 
> for great ideas (which, as I understand it, does occur .. 
> ranges for example).

No, there are thousands of such languages. Each university has a 
handful of languages that they create in order to back their 
comp.sci. research.

No need to focus on performance in that setting.

> You seem to be saying that, raising money so you can pay 
> people, is enough.
>
> But I wonder about that.

There has to be a focus based on analysis of where you can be a 
lot better for a specific use scenario, define the core goals 
that will enable something valuable for that scenario, then cut 
back on secondary ambitions and set up a process to achieve those 
core goals (pertaining to a concrete usage scenario).

Being everything for everybody isn't really a strategy. Unless 
you are Amazon, and not even then.

Without defining a core usage scenario you cannot really evaluate 
the situation or the process that has to be set up to change the 
situation...

Well, I've said this stuff many times before.