On Monday, 2 April 2018 at 12:33:37 UTC, Atila Neves wrote:
On Friday, 30 March 2018 at 16:41:42 UTC, Jonathan Marler wrote:
Seems like you're comparing apples to oranges.
No, I'm comparing one type of apple to another with regards to
weight in my shopping bag before I've even taken a bite.
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.
It's over an order of magnitude more code
More lines of code is a liability, not an advantage.
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.
and it's only fair to compare the "non-unittest" version of
std.path with Go, since Go does not include unittests.
Absolutely not.
There is *0* compile-time penalty on Go programmers when they
test their programs, whereas my compile times go up by a factor
of 3 on a one-line program. And that's >3 multiplied by
"already slow to begin with".
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. In practicality, D should
not be compiling in the standard library unittest by default.
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.
