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?

If we're serious about being fast, we better get our act together and:

- Make the GC faster, preferably on par with Java's best;

- 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";

- Replace commonly complained-about slow modules like std.json and
  std.xml with faster (and better-designed) replacements;

- Make dub run faster -- I can't help feeling frustrated when every time
  I invoke dub it takes 10-20 secs to scan the network for updates, then
  another 5-10 seconds to resolve dependencies, and *then* build it,
  when dmd itself is well capable of running an order of magnitude
  faster than that on a comparable amount of code.

- Shorten PR waiting times on Github. Some trivial PRs sit for weeks
  before even being noticed; kinda makes "fast code, fast" more of an
  ironic statement than a proud banner, y'know? (I've been diving into
  the deep end of the Phobos PR queue to declog old stuck PRs. Managed
  to bump the queue size from 100+ down to about 89 or so, but more help
  would be much appreciated. Sometimes I feel like a fast food janitor.
  Or fast code janitor. :-P)

- Provide an option to turn on GC collection (or *any* memory
  management, really) in dmd. I know it never frees memory because of
  "performance" reasons. But performance ain't gonna mean squat on a low
  memory system when you run out of memory and start swapping... or
  worse, invoking the kernel OOM killer. Then "fast code, fast" becomes
  "no code, killed". So much for fast. "How fast can you invoke the OOM
  killer?" :-P  I'd rather wait for a few more seconds and get an
  executable, than to shave off a few seconds and get zilch.


T

-- 
"The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell.
"How come he didn't put 'I think' at the end of it?" -- Anonymous

On Saturday, 3 February 2018 at 06:15:31 UTC, Joakim wrote:
> Software evolves. It isn't designed. The only question is how strictly you
> _control_ the evolution, and how open you are to external sources of
> mutations.

Unix was designed... and was based on a more ambitious design (Multics).
Linux was a haphazard kitchensink DIY reimplementation of it...

I wouldn't trust Linus much when it comes to general statements about software development.

Evolution does not mean that you don't design.

Cars evolve, but they sure are designed.

On Saturday, 3 February 2018 at 10:55:41 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 3 February 2018 at 06:15:31 UTC, Joakim wrote:
>> Software evolves. It isn't designed. The only question is how strictly you
>> _control_ the evolution, and how open you are to external sources of
>> mutations.
>
> Unix was designed... and was based on a more ambitious design (Multics).
> Linux was a haphazard kitchensink DIY reimplementation of it...
>
> I wouldn't trust Linus much when it comes to general statements about software development.
>
> Evolution does not mean that you don't design.
>
> Cars evolve, but they sure are designed.

I suggest you read all his comments in that thread, as I told you to in a previous forum thread before, as basically every statement you make here was addressed by other Linus emails in that archive I linked above.

On Saturday, 3 February 2018 at 04:16:25 UTC, Walter Bright 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

I think this (below) might be closer to your intention...(idea taken from a google tech talk)

"Life's Too Short - Write Fast Code, fast."

On Saturday, 3 February 2018 at 04:16:25 UTC, Walter Bright 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

You forgot the most important word:

Fast, correct code, fast

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.

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.

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

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?

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)