My choice to pick Go over D ( and Rust ), mostly non-technical

[Rubn]

On Saturday, 3 February 2018 at 23:07:30 UTC, Norm wrote:
> On Saturday, 3 February 2018 at 15:22:37 UTC, Rubn wrote:
>> On Saturday, 3 February 2018 at 08:18:57 UTC, H. S. Teoh wrote:
>>> On Fri, Feb 02, 2018 at 08:16:25PM -0800, Walter Bright via 
>>> Digitalmars-d wrote:
>>>> On 2/2/2018 7:06 AM, Benny wrote:
>>>> > Other languages have slogans, they have selling points.
>>>> > 
>>>> > When i hear Go, you hear uniformal, fast, simple syntax 
>>>> > language.
>>>> > When i hear Rust, you hear safe, manual memory management.
>>>> > When i hear D, you hear ... ... ... ...
>>>> 
>>>>                           Fast code, fast
>>>
>>> Frankly, that slogan makes me cringe. Makes D sound like a 
>>> fast food chain -- cheap code, fast. Would you like fa^Wfries 
>>> with that?
>>
>> Yup I agree, it's a horrible slogan. Speed isn't even a 
>> priority in D, if it was so many things would be different.
>>
>>> - Make dmd's optimizer better, esp. with loop unrolling on 
>>> par with
>>>   ldc/gdc, or better, so that we don't keep having to defend 
>>> poor dmd
>>>   benchmarks with "use ldc/gdc instead";
>>
>> I don't think time should be wasted on making DMD's optimizer 
>> better. It's not an easy job and it'll just pull resources for 
>> something that has no purpose. The compile times with DMD -O 
>> can vary dramatically, it's best just to not use it at all. 
>> The reason I hear as to why DMD even exists instead of just 
>> having 1 compiler like Rust or any other language that isn't 
>> 20+ years old. Is cause DMD's unoptimized compilation is fast 
>> and creates reasonably fast enough code for debugging.
>
> I agree, DMD should switch to LLVM backend. But it is unlikely 
> to happen because the core DMD developers are in their comfort 
> zone with DMD backend and worried that switching to LLVM would 
> put them at the mercy of the LLVM community. To be honest 
> though I don't know how much time DMD backend optimizer really 
> takes core devs away from D language development. It would be 
> interesting to see some numbers on this.
>
> We use LDC exclusively where I work because DMD codegen just 
> isn't production ready. And the argument that DMD debug builds 
> are so much faster than LDC is bogus. Yes it is faster but 
> nowhere near the point where we would consider swapping 
> compilers between debug and release builds.
>
> So that leaves little scripts and the like where DMD could 
> maybe replace Python. But again, LDC isn't *that* slow in debug 
> builds either and could do this just as well.
>
> Cheers,
> Norm

I agree it isn't that much faster, though that's the argument I 
hear. I would prefer to have one compiler that is being worked on 
than having split effort for 3 different compilers when larger 
communities only have 1 compiler. Not that everyone working on 
those compilers will work on one compiler if it does happen. It's 
just a shame the solution was to create more compilers.

With DMD it seems like they are entirely unwilling to let go from 
using DM tools/code. The backend is just one example. Optlink is 
another. DM Make is also another, etc...