My Experience at JuliaCon

Macros are documented along with everything else in the standard library:

http://docs.julialang.org/en/latest/stdlib/base/

The stdlib docs are organized by subject matter. What would the benefit of having a separate index of macros be? If one wants a list of exported macros, that's just a matter of doing

    grep @ base/exports.jl

in a Julia repo.

Not sure that I understand the point/tone of your comment, all that you say is correct and I am not unaware of any of those points nor do I contradict them in mine, but it seems that you are offering it as a correction. From your comment it seems that you are aware of the two different meanings of "vectorization" but that you are choosing the wrong one to setup a strawman. So I am a bit puzzled. In any case let me offer some clarifications:

The canonical example of ET and the one that started it all is Blitz++ (unlike its modern descendants it actually handles full n-dimensional tensors). More recent solutions are Blaze, Eigen and Armadillo. I like these over uBLAS (more verbose and not as performant). Blaze is typically the fastest (in this class) as long as you are dealing with 2D arrays and linear algebraic operations. Since Julia is homoiconic and has hygienic macros, one does not have to resort to such syntactically complex ways of doing metaprogramming such as ETs in C++. ET's are great to use, not very pleasant to write the machinery for, although things like Boost::spirit and fusion make it more tolerable. Heaven forbid that you have to understand the error messages though.

Now, to another point, looping is so pathetically slow in R, Numpy and Matlab (in that order) that the traditional solution offered in these languages is to vectorize (in the Matlab/numpy/R sense not in the SIMD sense) the loops into vector-expressions. Often this needs the help of extra prefilled vectors/matrices, (some languages do it smartly with 'broadcasting', some where late to pick it up, looking at you Matlab). Even with broadcasting tricks, the extra stride indirection in the iteration slows down the code from how fast it could have been. That is but one aspect of it, the other is chaining several binary and unary operations together. This also creates temporaries and unnecessary loops (unless you use solutions of somewhat limited scope like numexpr, which BTW is lovely when it is applicable, it also does thread level parallelization as well as SIMD if you can afford to link with intel MKL).

In Julia there is no need to avoid loops because they are inherently fast. In fact they are faster than the vectorized expressions, because of inefficiencies mentioned. However, loops are a lot more verbose than expressions. So this is where devectorize comes in. It transforms those expressions into loops (much like ETs) which can then be JITed to obtain superior performance. Now with SIMD vectorization thrown in on top, one can gain even more, because now one can benefit further from the instruction level parallelism. So yes you devectorize and then vectorize (and you already know this) and the term "vectorization" refer to two different concepts named vectorization , the clash in terminology is rather unfortunate.

EDIT: @scott_s no offense taken and upvoted. As I said, this post was just to offer some clarifications, the clash in terminology indeed gets very confusing. So, thanks for making me improve my comment, if it confused you I am sure it would have confused others as well.

I think you are getting at this above and what I've written below is somewhat redundant with srean's followup, but to clarify, writing vectorized code is mostly orthogonal to using SIMD vector instructions to compute the result. A sufficiently smart compiler can turn a loop into SIMD instructions, and these days most compilers (including LLVM, which Julia uses) are pretty good at that.

The problem that Julia solves here is that many scientific programming environments require you to write vectorized code, because they are interpreted and so looping through the elements in a vector incurs massive interpreter overhead. In some cases, this can make your code much more difficult to understand than if you wrote an explicit loop, but even when it does not, it often forces you to give up performance that could be obtained if you could write the code in a devectorized manner.

For example, consider the problem of calculating the variance of a sample. To calculate the variance in MATLAB, one might write:

  mu = mean(x)
  sum((x - mu).^2) / (length(x) - 1)

Although I don't know the details of how MATLAB optimizes this code, I do know that it has roughly equivalent performance characteristics to Julia code that first computes x - mu, then computes abs2(x - mu), then sums along the result. With an interpreter, you can't do much better, and this is actually how the MATLAB var function does it. In Julia, we compute the variance as:

  mu = mean(x)
  v = 0.
  for i = 1:length(x)
      v += abs2(x[i] - mu)
  end
  v / (length(x) - 1)

This is several times faster than MATLAB's included var function, because the computations performed on each element are cheap relative to the cost of memory access. If you wrap the loop in the @simd macro and add @inbounds to eliminate the bounds check when accessing x, the LLVM loop vectorizer will actually take that loop and translate it into SIMD instructions, making it even faster. (The @simd macro is necessary to tell LLVM that it's okay to vectorize, since accumulating into n variables and summing them at the end gives different [but usually more accurate] results compared to accumulating into a single variable due to floating point rounding.)

The promise of Devectorize.jl is that you will be able to write the first code fragment and have it transformed to the second, which would be neat indeed.

I think the best route is to create shared libraries using Julia and call them from R.

It seems like MCMC is a potentially killer app for Julia. Any thoughts as to how Julia's MCMC facilities compare to, say, something like Stan?

Second that. The purpose of Julia is not to replace every other language that people use for technical computing. I personally use Python for other projects (www.circuitscape.org), and only recommend using Julia for new classes of problems that need Julia's performance and capabilities. That class of problems keeps expanding over time.

RStudio looks really impressive. I have heard reliably that they do use the AGPL license and legal threat to get people to pay up for RStudio licenses. I have nothing against people charging for good software, but this sounds like some sort of bait and switch. I wonder if someone else can confirm if this is actually true.

Well I would think they would pay for RStudio server. I know $10,000 seems steep but I am sure Google could afford that.