D is dead

[Shachar Shemesh]

On 23/08/18 15:55, Steven Schveighoffer wrote:
> This whole thread seems very gloomy and final, but I feel like the tone 
> does not match in my mind how D is progressing. "Every single one of the 
> people [at Weka] rushing to defend D at the time has since come around." 
> Seems like you all have decided to either ditch D internally, maybe 
> moving forward, or accepted that Weka will fail eventually due to the 
> choice of D? It sure reads that way.

I'll clarify, in order to not create the wrong impression.

No, Weka is neither ditching D, nor is it banking on failing. We're 
doing pretty good as a company, and D will not change that.

What I did mean by that is that the enthusiasm from D has *greatly* 
diminished. Many (but not all) developer will definitely not choose D 
for our next project, should the choice be ours to make.

Like I said in my original post, it is not even in consensus whether 
picking D to begin with had been a mistake. Some think it was, some 
think, even in hind sight and after being more or less disillusioned, 
that it was still better than picking another language. As such, it is 
not even universally true that engineers at Weka regret going with D.

I think Mecca is a great library, and I'm very proud of writing it. 
There are certainly aspects of it that would not be possible (or, at 
least, highly impractical) in any other language I know.

With that said, it is also true that there are aspects of Mecca where D 
was holding me back from doing stuff I knew I could do much easier in 
C++. There were also areas where run-time bugs were discovered during 
integration with the main Weka code base (integration that is still 
ongoing) that were difficult to diagnose at best (and yes, I have it on 
my todo list to submit a PR to fix some aspects of some of them).

Example of something I couldn't/wouldn't do in any other language: the 
second form of spawnFiber:
https://weka-io.github.io/mecca/docs/mecca/reactor/Reactor.spawnFiber.html

The fact that the arguments for spawnFiber are the arguments for F, and 
that's verified by the compiler, no casts, no inference, no code bloat, 
is huge. I am sorely going to miss it at my next project (which, like I 
said, will not be written in D).

On the other hand, look at ConnectedSocket.connect:
https://weka-io.github.io/mecca/docs/mecca/reactor/io/fd/ConnectedSocket.connect.html

Why do I need two forms? What good is that? Why is the second form a 
template? Answer: Because in D, structs can't inherit, and I cannot 
define an implicit cast. What I'd really want to do is to have 
SockAddrIPv4 be implicitly castable to SockAddr, so that I can pass a 
SockAddrIPv4 to any function that expects SockAddr.

Except what I'd _really_ like to do is for them to be the same thing. 
I'd like inheritance. Except I can't do that for structs, and if I 
defined SockAddr as a class, I'd mandate allocating it on the GC, 
violating the whole point behind writing Mecca to begin with.

----

To summarize: Weka isn't ditching D, and people aren't even particularly 
angry about it. It has problems, and we've learned to live with them, 
and that's that. The general consensus, however, is that these problems 
will not be resolved (we used to file bugs in Bugzilla. We stopped doing 
that because we saw nothing happens with them), and as far as the future 
of the language goes, that's bad news.

Shachar