D is dead

[rjframe]

On Thu, 23 Aug 2018 21:04:36 +0300, Shachar Shemesh wrote:

> On 23/08/18 20:52, bachmeier wrote:
>> On Thursday, 23 August 2018 at 17:19:41 UTC, Ali wrote:
>>> On Thursday, 23 August 2018 at 16:22:54 UTC, Shachar Shemesh wrote:
>>>> On 23/08/18 17:01, Steven Schveighoffer wrote:
>>>> My main job is to develop for Weka, not develop D itself.
>>>
>>> Weka, at some point, made the strategic decision to use a non
>>> mainstream language
>>>
>>> I dont think Weka, have a choice, they have to invest in the
>>> development of D itself
>> 
>> I hope a startup can choose D without having to do that. Otherwise D is
>> not really a viable option for startups because they need to focus on
>> survival rather than language development.
> 
> This!
> 
> Maybe Weka can afford it, but being all smug about it is a destructive
> attitude to have. I know that some of Weka's leadership are
> uncomfortable about the fact that we, almost by definition, are facing
> language related issues that no-one in the community has before us.
> 
> Weka is in a good place, and is going in a good direction, but don't
> forget that we are up against giants, and are selling a product where
> 0.1% failure is considered the same as utter failure. Being able to
> trust the compiler was supposed to be a given.
> 
> Yes, Weka is, at this point, committed. The next start-up isn't.
> 
> Shachar


I don't really understand this reasoning; a compiler is a dependency, much 
like a third party library. When a dependency gets in the way of your 
product, you have to make a choice.

If you can't afford 0.1% failure, then if the compiler is holding you 
back, the choice seems to be fix the compiler, replace the compiler/
language, or don't do what you want to do.

Should you have to fix the bugs you run into? No. But if they keep you 
from doing your work, it seems like the economics of fixing D's bugs can 
make sense. If Weka were to assign its own priorities to D's bugs*, and 
have one person, once a week, fix the largest-priority bug, how big of an 
investment would that be, and would the return be worth it? Many bugs will 
definitely not be worth your time, but others might.


* I don't know that it's common, but I have maintained third-party bugs in 
my own tracker; this makes it easy to check their changelog against the 
bugs I care about, especially when I don't subscribe to the bug in their 
tracker for one reason or other. Being able to prioritize their bugs 
against bugs in my own project also helps me decide whether to spend my 
time fixing the third-party library.