3 ms·

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

by jabl 8y ago

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).

dnautics 8y ago
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.