Nope! C ain’t an insurmountable barrier like the speed of light is. It’s not necessarily able to natively express the fastest possible implementation for some algorithms. But, similarly, Julia might not be able to, either.
They’re all just languages that are trying to give you the ability to express (and then compile to) the fastest set of instructions for a given architecture with varying levels of success.
In [2]: a = np.random.rand(512000)
In [3]: %timeit np.min(a)
44.6 µs ± 853 ns per loop (mean ± std. dev. of 7 runs, 10,000 loops
each)
julia> @be rand(512000) fast_minimum samples=100 evals=50
mean 38.949 μs
Julia is actually faster if you enable fastmath like Numpy does.
For fun, this is the kernel internally used by Julia on v1.13 (and soon v1.12 too):
For all reductions, not just min/max. BTW, @mbauman Remove bugged and typically slower `minimum`/`maximum` method by mbauman · Pull Request #58267 · JuliaLang/julia · GitHub should have deleted
right?
They still may! 
I’m still trying to figure out how to better express this implementation in a way that’s both more generic and more easily (and perhaps even documentedly?) specializable. This may yet change in bigger ways.
testing against Julia nightly:
In [2]: import numpy as np
...:
...: A = np.random.rand(2026,51,251)
...: %timeit np.max(A)
3.71 ms ± 32.5 μs per loop (mean ± std. dev. of 7 runs, 100 loops each)
julia> @btime maximum(A)
4.789 ms (0 allocations: 0 bytes)
0.9999999129587941
julia> @btime @fastmath maximum(A)
3.531 ms (0 allocations: 0 bytes)
0.9999999129587941
On my architecture (AMD), I see no improvement going from 11.5 to today’s nightly, nor of any of the alternatives suggested above. Wonder why.