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.
