D compiles fast, right? Right??

[Jonathan Marler]

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

You still missed my point.  You're post was saying that "D does 
not compile as fast as GO". But the libraries you're comparing 
are vastly different.  If you're post was saying, "dlang's 
std.path compiles much slower than GO's" then you would be fine.  
However, you're post was misleading saying the Go compile's 
faster than D in general, and I was pointing out that the use 
case you provided doesn't apply in the general case, it only 
applies to a library with the same name/type of functionality.


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

I refer to my previous answer.  Your example shows that dlang's 
std.path compiles slower than GO's, but that doesn't say anything 
about the compile performance for both languages in the general 
case.  To make such a claim you should compare the exact same 
"functionality" implemented in both languages.


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

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.

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

You totally misunderstood what I was saying once again.  I agree 
with what you said here, but it has nothing to do with what I was 
saying.

If your point is that it takes too long to access std.path's 
functionality then I completely agree. What I am arguing against 
is that your example is not evidence that GO compiles faster than 
D in general. You're example is comparing 2 different libraries 
in 2 different languages, not about the languages themselves.