D compiles fast, right? Right??

[Atila Neves]

On Monday, 2 April 2018 at 18:52:14 UTC, Jonathan Marler wrote:

> My point was that GO's path library is very different from 
> dlang's std.path library.  It has an order of magnitude less 
> code so the point was that you're comparing a very small 
> library with much less functionality to a very large one.

I understood your point. I'm not sure you understood mine, which 
is: I don't care. I want to get work done, and I don't want to 
wait for the computer.

> I didn't say anything about whether it was advantageous, the 
> point was that it's more code so you should take that into 
> account when you evaluate performance.  You're post was 
> misleading because it was assuming that both libraries were 
> comparable when in reality they appear to be very different.

I disagree. They're very similar in the sense that, if I want to 
build a path and want to rely on the standard library, it takes 
vastly different amounts of time to compile my code in one 
situation vs the other.


> My point was that if you want to compare "compile-time" 
> performance, you should not include the unittests in D's time 
> since Go does not include unittests.

"Go does not include unittests"? Under some interpretations I 
guess that could be viewed as correct, but in practical terms I 
can write Go tests without an external library 
(https://golang.org/pkg/testing/)/ Whether it's a language 
keyword or not is irrelevant.

What _is_ relevant (to me) is that I can write Go code that 
manipulates paths and test it with everything building in less 
time that it takes to render a frame in a videogame, whereas in 
D...

> In practicality, D should not be compiling in the standard 
> library unittest by default.

I think everyone is in agreement here.

> This is a problem that should be fixed but still doesn't change 
> the fact that not taking this into consideration would be an 
> unfair comparison.

No, no, no, a thousand times more no.

We can't make a marketing point of D compiling so fast it might 
as well be a scripting language when it's not even true. I get a 
better edit-compile-test cycle in *C++*, which is embarassing.

Atila