Nothing magical, it certainly compiles specialized code to the types of arguments. Note that for such a simple benchmark you can get that function to be fast with standard python acceleration tools:
In [11]: from numba import jit
In [12]: @jit(nopython=True)
...: def fib(n):
...: if n == 0 or n == 1:
...: return n
...: elif n == 2:
...: return 1
...: else:
...: return fib(n - 1) + fib(n - 2)
...:
In [13]: %timeit fib(40)
296 ms ± 1.85 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
which here ran actually faster than the julia code sometimes:
julia> @btime fib(40)
350.784 ms (0 allocations: 0 bytes)
102334155
(after trying again, I get ~272 ms here, so there are fluctuations)
Thus these micro-benchmarks serve only to show that languages (or tools within the languages) can achieve performances of the order of the best possible ones. But they don’t really say anything about how useful will be the language, or the tool. That remains to be seen for Mojo, being the compatibility with python something that makes it useful to start, but I guess for now nobody really knows how it will be more useful than these python compilers like numba for everyday use, when integration with the python ecosystem starts to be tested.
As a side note: this type of comparison is sort of a Julia curse, and will be a Mojo curse as well. Julia users (myself included) can easily get snipped in testing that Julia can be fast in any benchmark that shows the opposite. And that comes from the fact that one central feature of Julia is its claim to be fast. That was more common a couple of years ago, as for now I think it is already accepted that Julia can be fast. Now people, like me, got bored of testing these things. Mojo will probably go through the same path, and while people are convinced that the language can be fast is that the other characteristics of the language (programing paradigms, ecosystem, etc) will prove the language interesting and useful or not for each application.