At the Debian Banechmark game, Julia is almost always fastest already, if best optimized (and precompiled) would be allowed, but the rules disallow, at least most often close.
But there’s also another way to win, on the objective metric size. I can see that people have been focusing more on speed…
Note size can be counted in different ways, lines of code, or tokens, not used there but compressed (gzipped) code size that approximates token-size.
While you could go to the unreadable extreme, e.g. d rather than depth variable here, please refrain from doing so (it’s also likely not too helpful because of the compression, and we want to be roughly comparable to the other languages):
We are beaten on speed for binarytrees, by many (most?) languages (thought not the otherwise fast non-GC language Chapel), e.g. Erlang on speed and size (for their fastest, our smallest is a bit smaller but not faster, and Python3 has smallest of all):
Erlang #2 4.61 459,720 478 13.63 69% 75% 74% 77%
There is a trade-off between size and speed, ideally we would be best on both at the same time, or some metric combining the two (that’s possible, but not any one correct, or what to emphasize more).
For speed please test with 1.10 (and/or master), e.g. 11312/13068 = 13.4% faster than 1.9.4, for this version:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/binarytrees-julia-4.html
We are at least always faster than Java (and Lisp), except for that one program (likely why Julia is by default compared to Java, considered in its category):
Here we are not in the general category, have been moved to " hand-written vector instructions | “unsafe” | naked ffi", where we are fast (still a bit slower, and larger, than even PHP in the general category), for 48% size overhead over Python (smallest entry):
60-72% larger than e.g. Perl, Ruby and PHP: