there's a reason why julia doesn't have a strong static type system.
In julia, you can write a custom type, and immediately have access to all of the builtin libraries.
For example, I wrote a drop-in replacement for floating points, and immediately had complex numbers, matrix math, gaussian elimination, fourier transform, etc... And could rapidly compare the numerical performance of that with fp.
For a more exotic example, I wrote a galois field GF256 type and was immediately able to reed-solomon encoding and decoding using the matrix multiplication and matrix solving libraries.
For an even more exotic example, I wrote a "lexical GF256" type (basically passing strings) and had the system generate optimized C code for reed-solomon decoding, using the builtin julia matrix solver without having to manually do matrix solving for every possible (n,k) reed-solomon system.
It was also relatively easy to write a verilog generator (~3 days of work), so you could pass bit-arrays representing wires, run you unit and property tests on the binary representation, then redispatch the function passing lexical types and get verilog code out the other end, then transpile the verilog to C using verilator, dynamically load the verilog into the julia runtime, and then unit and property tests on the transpiled verilog.
I'm sure it's possible to do this in haskell, but I imagine it would be harder.
I don't see why what you've done couldn't in principle be done in a language with a static type system (except maybe with some difficulty the thing with verilog, which apparently needs access to the compiler at runtime?)
To get good performance with a static type system, you need generics. Which means longer compile times, as the libraries you use must be compiled as part of your project so that the code specialized for the types you're calling the library with is generated. You can't have piles of native code lying around just waiting to be used (like in the C world, for example).
But this is similar to how Julia does it at runtime, with the multi-methods being JIT-compiled for the types you're calling them with. So either way you pay the cost somehow (and yes, there are ways to reduce that overhead, of course).
the primary use case for julia is where you expect to be doing computationally-intensive work over and over again (e.g. in a supercomputer deploy where I was using 20 HPC nodes over the course of 4 days), so the amortization of the (short) recompile time is worth it, and the ease of writing software using the julia generics is totally worth it. Also see the Celeste.jl project where they were able to very easily optimize for a super inconvenient platform (xeon phi).
If you're expecting a high-performance jit that needs to be called all the time because your program gets unloaded from memory and needs to be rebuilt by a kubernetes server every fifth web request, don't use julia.
In julia, you can write a custom type, and immediately have access to all of the builtin libraries.
For example, I wrote a drop-in replacement for floating points, and immediately had complex numbers, matrix math, gaussian elimination, fourier transform, etc... And could rapidly compare the numerical performance of that with fp.
For a more exotic example, I wrote a galois field GF256 type and was immediately able to reed-solomon encoding and decoding using the matrix multiplication and matrix solving libraries.
For an even more exotic example, I wrote a "lexical GF256" type (basically passing strings) and had the system generate optimized C code for reed-solomon decoding, using the builtin julia matrix solver without having to manually do matrix solving for every possible (n,k) reed-solomon system.
It was also relatively easy to write a verilog generator (~3 days of work), so you could pass bit-arrays representing wires, run you unit and property tests on the binary representation, then redispatch the function passing lexical types and get verilog code out the other end, then transpile the verilog to C using verilator, dynamically load the verilog into the julia runtime, and then unit and property tests on the transpiled verilog.
I'm sure it's possible to do this in haskell, but I imagine it would be harder.