February 03, 2018
On Saturday, 3 February 2018 at 23:25:09 UTC, welkam wrote:
> On Saturday, 3 February 2018 at 22:59:06 UTC, Dgame wrote:
>> This could be used to improve D
>
> So when will you start working on issues he described?

And when will you? I already tried in the past as you can see.
February 03, 2018
On Saturday, 3 February 2018 at 23:29:58 UTC, Christof Schardt wrote:
> On Saturday, 3 February 2018 at 22:59:06 UTC, Dgame wrote:
>> I congratulate you on your decision. I also changed to another language and I've never regretted it.
> Which is...? (just out of curiousity, btw I'm currently watching nim, after long years monitoring D and buying every book)

First back to C++11/14/17. Since 2017 I'm mostly using Rust.
February 03, 2018
On Saturday, 3 February 2018 at 23:39:00 UTC, Dgame wrote:
> On Saturday, 3 February 2018 at 23:29:58 UTC, Christof Schardt wrote:
>> On Saturday, 3 February 2018 at 22:59:06 UTC, Dgame wrote:
>>> I congratulate you on your decision. I also changed to another language and I've never regretted it.
>> Which is...? (just out of curiousity, btw I'm currently watching nim, after long years monitoring D and buying every book)
>
> First back to C++11/14/17. Since 2017 I'm mostly using Rust.

Then why are you posting here? Your post was 100% troll.
February 03, 2018
On Saturday, 3 February 2018 at 23:37:43 UTC, Dgame wrote:
> On Saturday, 3 February 2018 at 23:25:09 UTC, welkam wrote:
>> On Saturday, 3 February 2018 at 22:59:06 UTC, Dgame wrote:
>>> This could be used to improve D
>>
>> So when will you start working on issues he described?
>
> And when will you? I already tried in the past as you can see.

Searched forums and didnt find any discussion on contributing. https://dlang.org/contributors.html
Doesnt show you either.

I already try but depression makes a very slow process
February 04, 2018
On Saturday, 3 February 2018 at 22:59:06 UTC, Dgame wrote:
> This is a nice, refreshing post. You state problems and why you switched to Go. You give a ton of informations (here and in your prior posts) why you did what you did and what problems you've seen. This could be used to improve D. But the regular reply you will get if you criticize D even a little is "You are wrong! D is great!" or "You have a point, but ...". You can watch these discussions regularly, it's really hilarious. It always ends in the same way: Criticism is being hunted down and after Page 3 you can only read how great D is and why.
> I congratulate you on your decision. I also changed to another language and I've never regretted it. Sadly the D community will never learn from those excelent posts which only wants to help D to become better than it is. It's really sad...
> I bet this post will also torn apart to bash any sign of criticism.

There is always friction, and often conflict, in the open source community.

Why? Because there is no dictator, dictating the terms of what people should do, how they should do it, when they should do it. There are no consequences for not submitting to some authority. People are free to think and do as they choose.

So if you want to be part of an 'real' open source community, you need to understand that fact - before you understand anything else.

This is why democracies are what they are - frought with fiction, and often partisan conflict - cause people are free to think for themselves - and this often leads to friction and conflict.

You need to be able to maturely deal with that friction and conflict.

Go try living in north korea. not much conflict there - you get inprisoned or shot if you do not think and do as the leader dictates.

Your suggestions are welcome. Just don't tell people that if they don't listen to them, then their community is bad. That's not how an open source community works.

If you are free to think and do, so are others.

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

There is very little split effort. The way this actually works is there's one D codebase that everyone works on, and three backends that basically nobody works on (they are done by independent teams).

The only work that's separate between dmd, gdc, and ldc is a little bit of code with adapter classes that just fit that shared D codebase into each of the three backends. That is a tiny, tiny fraction of the work done since it doesn't actually reimplement any of the guts.

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

D uses the Visual Studio linker and the GNU or LLVM linker as well as GNU make on all platforms except 32 bit Windows.
February 04, 2018
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
February 04, 2018
On Saturday, 3 February 2018 at 23:45:21 UTC, bachmeier wrote:
> On Saturday, 3 February 2018 at 23:39:00 UTC, Dgame wrote:
>> On Saturday, 3 February 2018 at 23:29:58 UTC, Christof Schardt wrote:
>>> On Saturday, 3 February 2018 at 22:59:06 UTC, Dgame wrote:
>>>> I congratulate you on your decision. I also changed to another language and I've never regretted it.
>>> Which is...? (just out of curiousity, btw I'm currently watching nim, after long years monitoring D and buying every book)
>>
>> First back to C++11/14/17. Since 2017 I'm mostly using Rust.
>
> Then why are you posting here? Your post was 100% troll.

It was not, your posts shows exactly what I meant. :)
February 04, 2018
On Sunday, 4 February 2018 at 01:46:34 UTC, psychoticRabbit wrote:
> Your suggestions are welcome. Just don't tell people that if they don't listen to them, then their community is bad. That's not how an open source community works.

I've never said that the community is bad. :)