An Updated Analysis for the “Giving Up on Julia” Blog Post
tk3369.wordpress.com
tk3369.wordpress.com
IMO, C/C++ are terrible languages for numerical computing. In a way, Python is terrible too, except that it's great at gluing together existing numerical code, and doing high-level modeling, data analysis and visualization. These are quite important, of course, but very distinct from the actual numerics (the "two-language problem" Julia aims to bridge)
All that being said, Julia's JIT-slowness can be a little annoying during development and testing, when you run Julia scripts on small example data, and have to wait 20 extra seconds every time you run the script! It would be really nice if Julia cached more of its compilation, so that any script being run repeatedly and invoking the same code paths with the same types would only cause compilation the first time.
This might help you out
That's not the favored way of working with languages that have a REPL (or better --- Jupyter notebooks). Ideally, you work and reload new code interactively. I only rarely have to restart Julia, so I don't have to pay the JIT tax very often. Check out Revise.jl
This is quite interesting. So potentially the code for other languages are not the best. It would complete the argument then that the "code patterns" is more often than not the most "natural" e.g. it translates well from pseudo-code.
When I was trying Julia I keep trying to vectorize code like I do in R and it took me a while to get comfortable with writing loops again. Vectorized code in R can be quite fast, but there is big caveat - you need a lot more memory to do the same task (until ALTEREP makes into R Base) . E.g. say I wanted to find the maximum of `abs(a^2)` in R where `a` is a vector, so I would do `max(abs(a^2)` this creates a temporary vector. In Julia I can do `maximum(x->abs(x^2), a)` and achieve similar (if not better performance) using much less RAM. This is qutie important if you deal with large datasets (e.g. Fannie Mae data at 1.8 billion rows).
It's important to optimize the performance critical code. And in my use cases scripts usually runs minutes or even hours.
It's hard to remember if some of the concerns raised were valid at the time, but as of now none of the criticisms seem to hold. To make a concrete example: Julia testing framework (Base.Test) is now very user friendly and widely used: with one command at the console one can generate a package which is already set up to be tested remotely on different architectures. As a consequence, package coverage is generally reasonably high.
I know The first time I got interested in Julia I was turned off by that article and it wasn’t till I came back later and started thinking about trying Julia again that I realized the article was bunk.