The Living Thing / Notebooks :


The hippest, most stylish way to get your IEEE 754 on

Julia: A JIT-compiled language that aims for high performance scientific computation.

It makes ambitious claims about being the fastest and best thing ever. The community process is problematic, (see also) however, and I prefer the proven method of using python and optimizing the performance sensitive code with one of the many tools to do that.


That said, the idea of a science-users-first JIT language is timely, and Julia is that. Python has clunky legacy issues in the numeric code and a patchy API. Matlab is expensive and nasty for non-numerics. Lua has some good science libraries and could likely have filled this niche but for AFAICT sociological reasons has not acquired the hipness or critical mass of Julia.

And there are some things specific to Julia which are serious selling points, aside from the language-feature one-upmanship.


See the API list

Calling C from Julia

Sort of easy, but there is a tedious need to define the call signature at call time. This will ideally get automated at some point/



This package provides an interface from R to Julia, based on the XR structure, as implemented in the XR package, in this repository.


rjulia provides an interface between R and Julia. It allows a user to run a script in Julia from R, and maps objects between the two languages.


Differentiating, optimisation, statistics

Laplacians.jl by Dan Spielman and co-workers is an advanced matrix factorisation toolkit.

The aspirational ggplot clone is gadfly.

Dataframes are called, unsurprisingly, dataframes.jl, and are part of the juliastats organisation

The deep learning toolkits are, for the moment, notably unimpressive. Perhaps they’ll get there?

tensorflow.jl. (Surely one misses the benefit of Julia by using tensorflow, since there are two different array-processing infrastructures to pass between?)

Flux.jl sounds more like a reimplementation of tensorflow inside julia, which seems to me to be the way you’d actually do this right:

Flux is a library for machine learning. It comes “batteries-included” with many useful tools built in, but also lets you use the full power of the Julia language where you need it. The whole stack is implemented in clean Julia code (right down to the GPU kernels) and any part can be tweaked to your liking.


Turing.jl is a Julia library for (universal) probabilistic programming. Current features include:

  • Universal probabilistic programming with an intuitive modelling interface
  • Hamiltonian Monte Carlo (HMC) sampling for differentiable posterior distributions
  • Particle MCMC sampling for complex posterior distributions involving discrete variables and stochastic control flows
  • Gibbs sampling that combines particle MCMC and HMC

The juliadiff project produces ForwardDiff.jl and ReverseDiff.jl which do what you would expect, namely autodiff.


ApproxFun.jl does Chebychev and Fourier interpolations.


There is a reasonable IDE called juno, built on atom. There is jupyter integration through IJulia.

ENV["JUPYTER"] = "/usr/local/bin/jupyter"

Now IJulia appears as a normal kernel in your jupyter setup.

Both these have their own annoyances. e.g. Juno is single-window only so you can’t really use multiple monitors.

There is a package called Weave.jl which is inspired by R‘s knitr but compatible with jupyter, which could probably be used to fashion a working academic paper out of this.

UIs and servers

HttpServer does basic http protocol serving; this is made modular and composable by Mux.jl. Fancy caching and templating etc come from Genie.jl.

Escher.jl goes further, rendering HTML UI widgets etc.

Various other options are listed in aviks’ stackoverflow answer.


It’s unstable and hangs all the time


Especially when it’s doing things that are supposed to be julia specialties, such as JIT-compiling dynamic inner functions. Just use the recommended julia command:

killall -9 julia

Workflow sucks


You are using Julia because it is dynamic and because it is fast, but if you try to use code in a dynamic fashion, in the global namespace, it is no longer fast. Many complicated interactions ensue, and the wrecommended workarounds have so far been highly unstable.

Latest workflow tips:

Put code under development in a temporary module. Create a file, say Tmp.jl, and include within it

module Tmp

<your definitions here>


Put your test code in another file. Create another file, say tst.jl, which begins with import Tmp and includes tests for the contents of Tmp. The value of using import versus using is that you can call reload("Tmp") instead of having to restart the REPL when your definitions change.

[…]Explore ideas at the julia command prompt.[]…] Occasionally restart the REPL, issuing


That’s fine. What works for me is running


Argument syntax is only OK

Keyword arguments exist but do not participate in method dispatch. Basically, keyword arguments are second-class citizens and might make things slow or stupid if you need to specialise your code.

AbstractFloats don’t work in Arrays

AFAICT if you want fast numerics but you are not sure of your float precision, you should not use AbstractFloat. This is unfortunate, since there are good reasons to use 32bit and 64 bit floats - e.g. GPUs - and writing the same code twice seems awkward. Presumably one can work around this using parametric types and parametric methods or typeof?