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

[Joakim]

On Sunday, 4 February 2018 at 01:57:26 UTC, Rubn wrote:
> 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.

All the major compilers, dmd, ldc, and gdc, share the same 
frontend.  Two of the backends, llvm and gcc, are not worked on 
by the D compiler devs.  The DM backend used by dmd is not worked 
on much, mostly bug fixes and some refactoring recently, as 
Walter prepares to move it to D:

https://github.com/dlang/dmd/commits/0b8d1fc0d5f6d09478d282202ad50a0c964b75b0?after=0b8d1fc0d5f6d09478d282202ad50a0c964b75b0+104&path%5B%5D=src&path%5B%5D=ddmd&path%5B%5D=backend

There is no evidence that having more compiler backends available 
to D devs has "split effort" in any way.

As for the compilers' speed, I thought I'd test that out.  I just 
built the dmd frontend a handful of times in a single-core 
linux/x64 VPS, both with the official dmd 2.078.0 and the latest 
ldc 1.7.0.  Leaving out all the C++ files, dmd consistently took 
3-4 seconds to build the D frontend alone and link the final dmd 
binary, whereas ldc took 9-10 seconds for the same work.  This is 
with no debug or optimization options added, just the default 
build by the dmd makefile.

That's a 200% increase in compilation speed when iterating on the 
almost 80k lines of code (reported by DScanner) in the dmd 
frontend, certainly not insignificant.  When the backend is in D 
too- the C++ files currently take about 10 seconds to compile- 
building dmd itself will be incredibly fast, even more than it is 
now.

> 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...

Why let it go, when you don't have to use it?  Optlink has around 
5 commits in the last 3 years, it's not like it's taking up much 
time:

https://github.com/DigitalMars/optlink/commits/master

Rather than worrying about DM tools that receive almost no 
attention, D would be better off if more people chipped in on the 
code they _do_ care about, whether through submitting pull 
requests or posting bounties:

https://github.com/dlang/dmd/pulls
https://github.com/dlang/phobos/pulls
https://www.bountysource.com/teams/d