On Tuesday, 3 April 2018 at 20:47:48 UTC, Kagamin wrote:
> On Friday, 30 March 2018 at 16:12:44 UTC, Atila Neves wrote:
>> * Building a whole project in C++ still takes a lot longer since D scales much better, but that's not my typical worflow, nor should it be anyone else's.
>
> I can write code for days without even saving :)

That sentence might as well be fingernails on a blackboard for me! I save compulsively. Whenever I stop typing, C-x C-s it is for me.

> What's the point to compile code that's not supposed to work?

TDD.

On Tuesday, 3 April 2018 at 21:53:35 UTC, bachmeier wrote:
> On Tuesday, 3 April 2018 at 21:17:35 UTC, Rubn wrote:
>> I feel that's probably the case for any comparisons across two languages, you are going to have a person that is more knowledgeable in one language than another. Mistakes are going to be made, but I think it should be blatantly obvious that one language is going to compiler slower if it is compiling all the unittests for a library compared to one that isn't. That's just blatant bias against D, not a mistake from misunderstanding Go.
>
> Yeah, I don't understand that either. Unit tests can be arbitrarily large, so no matter how fast the compiler, it would always be possible to make it take longer than any other language.

There were 0 tests in my example.

Atila laid it out pretty clear: he doesn't care about the differences, he wants the work to be done. And I'm with him on that. Go and it's standard library may be way simpler, but it get's the job done (which is trivial in both cases, by the way) almost instantaneously, which is a much bigger deal than it seems to be. When your edit-compile cycle is that fast, it changes the way you write code, you develop a habit of writing smaller pieces of code and testing them more frequently. Remember that Linus Torvalds' talk about Git at Google?
https://www.youtube.com/watch?v=4XpnKHJAok8&t=3025

H. S. Teoh is not the only one here cringing at "fast code fast" on the main page. I use D from time to time for over 10 years now, and even used it at work and it was a relatively positive experience, thanks to vibe.d. But compilation times are just horrible - minimum 3 seconds for a 1500 lines project (on a 8-core 4GHz CPU with 16 GB RAM), and that's after I ditched std.regex, made all imports qualified (didn't help that much, though) and switched to ld.gold. And I would be ok with slow compilation if DMD was smart enough, doing some graph magic, like extensive control flow analysis, and insane optimizations, but it doesn't. For example, Rust compilation times are no picnic either, but it's obvious why - you get nice good-looking error messages, tons of useful warnings and very fast programs free of memory corruption bugs. It's not the case with DMD, though. The language may be better than C++, but it's fastest compiler is slower and produces worse code? I'd rather not boast about speed at the main page in this situation. And god save us from ridicule by Goers.

On Tue, Apr 03, 2018 at 10:59:13PM +0000, Atila Neves via Digitalmars-d wrote:
> On Tuesday, 3 April 2018 at 20:47:48 UTC, Kagamin wrote:
> > On Friday, 30 March 2018 at 16:12:44 UTC, Atila Neves wrote:
> > > * Building a whole project in C++ still takes a lot longer since D scales much better, but that's not my typical worflow, nor should it be anyone else's.
> > 
> > I can write code for days without even saving :)
> 
> That sentence might as well be fingernails on a blackboard for me! I save compulsively. Whenever I stop typing, C-x C-s it is for me.
[...]

Yeah, after having lost valuable work more often than I'd care to admit due to unexpected power outages and other hardware problems, I've developed a compulsive twitch in my fingers that automatically saves my file every other minute.  It has become so automatic that it's basically unconscious now.  I can't imagine not saving for long periods of time.


T

-- 
All men are mortal. Socrates is mortal. Therefore all men are Socrates.

On Tuesday, 3 April 2018 at 19:07:54 UTC, Jonathan Marler wrote:
> On Tuesday, 3 April 2018 at 10:24:15 UTC, Atila Neves wrote:
>> On Monday, 2 April 2018 at 18:52:14 UTC, Jonathan Marler wrote:
>>


> You still missed my point.

I got your point. I'm disagreeing.

> You're post was saying that "D does not compile as fast as GO".

Please show me where in my post where you think I said that.

> But the libraries you're comparing are vastly different.

Their sizes are different. I disagree that they're vastly different.

> If you're post was saying, "dlang's std.path compiles much slower than GO's" then you would be fine.

That is exactly what I said.

> However, you're post was misleading saying the Go compile's faster than D in general,

I never said that.

> and I was pointing out that the use case you provided doesn't apply in the general case,

Maybe it applies in the general case, maybe it doesn't. I have no idea.

> it only applies to a library with the same name/type of functionality.

I don't know about “only".


> You're totally misunderstanding me.  I was just saying that if you want to compare the compile speed of D vs GO (IN THE GENERAL CASE), you should not include the unittests in D's performance because you weren't including them in your GO example.

Include what? The Go standard library's own tests? libstdc++'s?

All the code I compiled was in that post. The only reason the Go file isn't just a one liner is because the silly opinionated language won't let me.

I showed how long it takes to compile the minimum amount of code necessary to import the part of the standard library responsible for paths in 3 languages. Then I showed how much slower it got in D with -unittest on the exact same one liner.

There isn't an equivalent in Go or C++. And yet one can write tests in them. And when one does, the compile-time penalty is 0.

> What I am arguing against is that your example is not evidence that GO compiles faster than D in general.

I have no idea why you're arguing against something I never stated.

> You're example is comparing 2 different libraries in 2 different languages, not about the languages themselves.

No, I compared importing path functionality in files that did nothing else (except for some dummy code in Go) in *3* different languages. Then I showed that compiling the one liner in D with -unittest was slower than C++ by just a bit and nearly 50 slower than Go. With no actual tests in sight.

On Tue, Apr 03, 2018 at 11:09:10PM +0000, burjui via Digitalmars-d wrote: [...]
> H. S. Teoh is not the only one here cringing at "fast code fast" on the main page. I use D from time to time for over 10 years now, and even used it at work and it was a relatively positive experience, thanks to vibe.d. But compilation times are just horrible - minimum 3 seconds for a 1500 lines project (on a 8-core 4GHz CPU with 16 GB RAM), and that's after I ditched std.regex, made all imports qualified (didn't help that much, though) and switched to ld.gold.

3 seconds for 1500 lines?  Is that because you're using dub with its unbearably slow compulsive network lookups?  Or because you imported monsters like std.format?  Or because you have heavily-templated code? Vibe.d is pretty heavy on templates (Diet templates, while pretty cool from a geekiness POV, also slow things down like a hog because of heavy template + CTFE usage).

Also, which compiler version did you use?  If you use nested templates heavily (like UFCS chains of ranges), in older releases you may have run into the exponential symbol size problem, where most of the compilation time is spent generating, looking up, and reading symbols that are tens of megabytes long.  After Rainers' symbol compression PR was merged, compilation times on such code was hugely improved. As of a release or two ago, this is no longer a problem.

I've noticed that if I don't use certain slow things, dmd is actually lightning fast at compiling up to several thousand LOCs.  But as soon as std.format enters the picture, or if you have recursive templates or heavy CTFE, it rapidly deteriorates.  (Note, though, that relatively simple template code doesn't significantly slow things down; it's when you start doing things like manipulating type tuples AKA AliasSeq's, recursive templates, compile-time loops like static foreach over introspection, heavy CTFE, that things start grinding. Simple parametrized types are still lightning fast, and last time I checked a lot faster than, say, equivalent C++ code compiled with g++.)


> And I would be ok with slow compilation if DMD was smart enough, doing some graph magic, like extensive control flow analysis, and insane optimizations, but it doesn't. For example, Rust compilation times are no picnic either, but it's obvious why - you get nice good-looking error messages, tons of useful warnings and very fast programs free of memory corruption bugs. It's not the case with DMD, though. The language may be better than C++, but it's fastest compiler is slower and produces worse code? I'd rather not boast about speed at the main page in this situation.  And god save us from ridicule by Goers.

These days, I don't even look at benchmarks of dmd-compiled code anymore.  For anything even remotely performance-related, I look at gdc/ldc.  They do compile noticeably slower than dmd, but with the huge benefit of far superior backends that gives me top runtime performance.

If Andrei & Walter are serious about this "fast code fast" thing, then we'd better get our act together and do some serious optimization work, both on the compiler itself, and on the quality of its codegen.


T

-- 
Bomb technician: If I'm running, try to keep up.

On Tuesday, April 03, 2018 16:15:35 H. S. Teoh via Digitalmars-d wrote:
> On Tue, Apr 03, 2018 at 10:59:13PM +0000, Atila Neves via Digitalmars-d
wrote:
> > On Tuesday, 3 April 2018 at 20:47:48 UTC, Kagamin wrote:
> > > On Friday, 30 March 2018 at 16:12:44 UTC, Atila Neves wrote:
> > > > * Building a whole project in C++ still takes a lot longer since D scales much better, but that's not my typical worflow, nor should it be anyone else's.
> > >
> > > I can write code for days without even saving :)
> >
> > That sentence might as well be fingernails on a blackboard for me! I save compulsively. Whenever I stop typing, C-x C-s it is for me.
>
> [...]
>
> Yeah, after having lost valuable work more often than I'd care to admit due to unexpected power outages and other hardware problems, I've developed a compulsive twitch in my fingers that automatically saves my file every other minute.  It has become so automatic that it's basically unconscious now.  I can't imagine not saving for long periods of time.

LOL. I save probably closer to every ten seconds, though I'm not sure exactly how often it is because of how automatic it is. It's highly dependent on when I finish a set of commands in vim, so with code, I tend to save _very_ frequently, whereas with text, it's a lot less frequent, because there, I often stay in insert mode for while. In addition to just generally being a good idea, it eliminates the need for vim's swap files, and I hate it when programs create files like that (be it to restore what you didn't save when the program crashes or as a backup file every time you save). The file is what is on disk, and I don't want the program trying to keep track of unsaved data or old data and make it easy for me to restore it when my computer crashes. That's what saving is for, and if I want older versions, I'll use source control. But I guess that there are folks who do a lot of typing without saving. I sure couldn't though.

Now, it is true that I frequently write a lot of code before bothering to compile anything - not days worth at a time though.

- Jonathan M Davis

On Tuesday, 3 April 2018 at 23:29:34 UTC, Atila Neves wrote:
> On Tuesday, 3 April 2018 at 19:07:54 UTC, Jonathan Marler wrote:
>> On Tuesday, 3 April 2018 at 10:24:15 UTC, Atila Neves wrote:
>>> On Monday, 2 April 2018 at 18:52:14 UTC, Jonathan Marler wrote:
>>>
>
>
>> You still missed my point.
>
> I got your point. I'm disagreeing.
>

I don't know why you keep saying you are "disagreeing" with me.  It looks like we agree.  You're example is showing that DLANG's std.path compiles slower than GO's path library.  I agree.  All I was saying is that this example doesn't show that GO code compiles faster than D.  That was my one and only point.

Am Tue, 3 Apr 2018 16:15:35 -0700
schrieb "H. S. Teoh" <hsteoh@quickfur.ath.cx>:

> On Tue, Apr 03, 2018 at 10:59:13PM +0000, Atila Neves via Digitalmars-d wrote:
> > That sentence might as well be fingernails on a blackboard for me! I save compulsively. Whenever I stop typing, C-x C-s it is for me.
> 
> […] I can't imagine not saving for long periods of time.

Me too, but for me it was Delphi 2005/2006 with frequent IDE crashes that had me start doing this and dmd eating into swap memory when I write messy CTFE code that keeps me doing Ctrl+S before before any action that has any likelihood to stall the system. I also don't trust my own code.

-- 
Marco

On 04/03/2018 05:53 PM, bachmeier wrote:
> On Tuesday, 3 April 2018 at 21:17:35 UTC, Rubn wrote:
>> I feel that's probably the case for any comparisons across two languages, you are going to have a person that is more knowledgeable in one language than another. Mistakes are going to be made, but I think it should be blatantly obvious that one language is going to compiler slower if it is compiling all the unittests for a library compared to one that isn't. That's just blatant bias against D, not a mistake from misunderstanding Go.
> 
> Yeah, I don't understand that either. Unit tests can be arbitrarily large, so no matter how fast the compiler, it would always be possible to make it take longer than any other language.

Exactly, which is why I'm insisting this - and not compiler benchmarking, let alone idle chattaroo in the forums - is where we need to hit. What we have here, ladies and gentlemen, is a high-impact preapproved item of great general interest. Shall we start the auction?