That's the trade off I guess, because of the JIT you have a slow initialization followed by very fast code.

That's not really good for a lot of workflows though (if you're running a smallish script over and over for example).

If you are running a script over and over (or using small modules to do organize things) it will be very fast and easy to work with. The compilation is just for the first time a script is run, not every time.

It really isn't a barrier any more than, say, waiting for `library` commands in R.

I don't think I've ever seen an R library() take more than about a second, and usually the action is complete as my finger is starting to raise from the 'return' key. When I tried "using Plots" in julia, it took several tens of seconds the first time, and several seconds in subsequent sessions. So, slower than R, but not terribly so. I suspect the real advantage of Julia is that it lets the analyst stick to a single language, without (as in the R case) having to write time-consuming components in C, C++, or Fortran.

For me the appeal is 3-fold

1) I can contribute to widely used packages like DataFrames and HypothesisTests. I had never made a git commit before this and my only "real" programming was CS 101 in Java. The fact that I could get up and running so easily contributing is a testament to the language's ease of use

2) I think its tough to predict your computational needs at the start of a project. Sure everything can be done in `lme` in R at the outset, but if you need some new bootstrapping procedure that a reviewer wants you might be left connecting some high performance code to an existing, large, R-based codebase. That's tough. I think Julia makes that "refactoring" (if you can call it that) easy.

3) Hopefully Julia will open a lot of doors for me in the future in my research career. I will be able to write interesting simulation procedures that are otherwise too unweildy for the comparison R or Stata economist.