

Julia 0.3 released - StefanKarpinski
http://julialang.org/blog/2014/08/julia-0.3-release/

======
idunning
For anyone curious about the packages available in Julia 0.3, please check out
[http://pkg.julialang.org/](http://pkg.julialang.org/). We hope to add
keywords and such in the near-term to make package discovery easier. Until
then you can check out some of the "organizations"
([http://julialang.org/community/](http://julialang.org/community/)) such as
JuliaStats ([http://juliastats.github.io/](http://juliastats.github.io/)) and
JuliaOpt ([http://juliaopt.org](http://juliaopt.org)). Finally, we have a blog
aggregator that you can follow at
[http://www.juliabloggers.com/](http://www.juliabloggers.com/)

Julia 0.3 is a solid release and many Julia users have been using the master
Github version for the past few months for production use, academic work, and
just messing around quite happily. There are relatively few breaking changes
from 0.2 to 0.3, with much better package support - so upgrade as soon as you
can.

Julia 0.4 is likely to be a more "unstable" release in the tick-tock style
that Linux used to have. Already been some great new things merged in, many
more to come. I'd recommend not using the master branch of Julia at this time,
and instead stay on release-0.3 if you like to build from source.

~~~
idunning
Sorry for self-reply, but ran out of edit time: a very valid concern about
Julia is the lack of packages because it is new - a catch-22 situation that
all new languages. This has been recognized by developers and Julia has now
got some great inter-language interop packages and functionality, allowing it
to harness a world of packages in other languages.

* Very efficient interaction with C and Fortran libraries is a core Julia feature, with the ability to pass arrays and structs directly between C and Julia.

Calling C: [http://docs.julialang.org/en/latest/manual/calling-c-and-
for...](http://docs.julialang.org/en/latest/manual/calling-c-and-fortran-
code/)

* Python libraries can be used through PyCall.jl, which is used most famously to call matplotlib (PyPlot.jl) but also other libraries like pandas (Pandas.jl).

PyCall.jl:
[https://github.com/stevengj/PyCall.jl](https://github.com/stevengj/PyCall.jl)

PyPlot.jl:
[https://github.com/stevengj/PyPlot.jl](https://github.com/stevengj/PyPlot.jl)

Pandas.jl:
[https://github.com/malmaud/Pandas.jl](https://github.com/malmaud/Pandas.jl)

* Java libraries can be used through JavaCall.jl, which is used in Taro.jl to call Apache Tika and Apache POI

JavaCall.jl:
[https://github.com/aviks/JavaCall.jl](https://github.com/aviks/JavaCall.jl)

Taro.jl: [https://github.com/aviks/Taro.jl](https://github.com/aviks/Taro.jl)

* R libraries can be called through Rif.jl

Rif.jl:
[https://github.com/lgautier/Rif.jl](https://github.com/lgautier/Rif.jl)

~~~
pygy_
It is still experimental, but the C++ FFI should also be mentioned:

[https://groups.google.com/forum/#!topic/julia-
dev/4kUu2ieWZ9...](https://groups.google.com/forum/#!topic/julia-
dev/4kUu2ieWZ9Q)

Some more samples:
[https://github.com/Keno/Cxx.jl/tree/master/test](https://github.com/Keno/Cxx.jl/tree/master/test)

------
apl
For fans of the Python numeric stack (NumPy, SciPy, pandas, etc.): if you ever
want to give Julia a go, there's an excellent Julia-to-Python bridge called
PyCall.

[https://github.com/stevengj/PyCall.jl](https://github.com/stevengj/PyCall.jl)

It allowed me to incorporate Julia into my academic work without breaking a
sweat.

------
thearn4
Python is my usual go-to language for technical computing, bit Julia is a lot
of fun! I'd be curious to hear more from folks who have made use of it in
"production" (sort of a tricky label in scientific programmiong) code.

~~~
oostevo
For what it's worth, I tried and failed to convert my team of
scientists/programmers (heavy on the science; not so much on the programming)
to Julia from MATLAB/IDL/C++ for a project we were kicking off ca. 1 year ago.

It's a really, really nice language that I find more consistent and easier to
grok than MATLAB, but the deciding factor was the lack of the equivalent of
MATLB toolboxes with all of their pre-rolled code that made our development as
fast as it was.

Edit: I should have mentioned: the Julia add-on packages are multiplying
quickly, and are starting to look mature!
[http://pkg.julialang.org/](http://pkg.julialang.org/) I'm looking forward to
them overtaking Mathworks on this front too.

~~~
jordigh
Octave dev here, which packages are you looking for?

I'm curious if it's as sophisticated as Simulink and Mupad, which are
completely different programs that happen to be associated to Matlab, or if
it's just the image package that we have almost all in Octave already.

Where's the demand? Where is _your_ demand? :-)

~~~
oostevo
This was at an organization that I don't work for anymore, and my recollection
is a bit fuzzy. I think it was Computer Vision, Signal Processing, Wavelet,
and Image Processing.

There were also some convoluted, non-technical reasons that we went with
MATLAB.

~~~
jordigh
Could you contact me at jordigh@octave.org for some follow-up questions?

------
roye
When I last looked at Julia (as a candidate for writing a bioinfo. tool) it
seemed a really appealing alternative to prototyping first in Python and then
Cythonizing to gain speed, in that code would only have to be written once and
no stitching together would be required. Ultimately, I decided against using
it because it seemed packaging of binaries wasn't quite there yet (e.g., one
would have to download Julia and then download my code to run it). Is this
something that's likely to be addressed in 0.4? Was my understanding of the
situation accurate?

~~~
one-more-minute
Yeah, that's exactly right. Static compilation is a high priority though, so
it will be possible eventually.

~~~
roye
Alright, thanks. I'll check in at the start of the next project :)

------
marcodena
I'm curious. I would like to know if it is worth to learn a new language only
for speed reasons or if it's better to hope in improvements in Python... What
do you think?

Anyway awesome! It's going well :))

~~~
andreasvc
If you subscribe to the idea of a division of labor between systems and
scripting languages, then Python + its C based extensions (Cython, Numpy,
etc.) is ideal, as it already has an extensive scientific ecosystem. Julia
combines the two in a single language. See this blog post and the one that
follows it:
[http://graydon2.dreamwidth.org/3186.html](http://graydon2.dreamwidth.org/3186.html)

~~~
srean
It is light years far from ideal. There are two variants of this much parroted
line (i) Numpy, Scipy are just C loops, and (ii) 'just do the intensive parts
in C', both leave a lot more to be desired.

Yes numpy, scipy indeed dispatch to precompiled C and sometimes Fortran loops
but the problem lies elsewhere, in its vectorization paradigm. It is just
extremely wasteful. There are two problems:

(a) it is not expressive enough to capture efficient computation without
generating unnecessary intermediate arrays whose sole objective is to make it
possible to write the computation as a vectorized operation. Unlike Matlab in
the past, numpy, scipy are at least smart about broadcasting. This often
allows one to avoid constructing those intermediates in memory. However, this
comes at an extra indirection that affects _all_ array operations via the
stride vector. You pay the cost of indirection whether you need it or not.

(b) The second problem is generation of temporaries when you chain several
binary operations. These temporaries get allocated, filled and destroyed over
and over again within a single expression which itself might be in a loop.
This costs computation, memory, not to mention GC pressure. There is of course
numexpr but it is also quite limiting. For instance you cannot index or slice
from within a numexpr expression. It offers limited set of reduce operations,
in an expression you can use only one, and it must be the last one in the
sequence of operations.

Then there is 'write to C'. If we have not eliminated the need to write C we
have not really solved the hard problems have we. I think the whole point was
to avoid writing low level code because it is error prone, tedious and that it
often comes at the cost of productivity. The drop down to C imposes an
unnecessary break in flow and forces you to tackle the impedance mismatch.
Tools like Cython eases this a bit. You cannot for example use numpy array
expressions efficiently from Cython, you have to write those tedious low level
indexing code. If I were to write C, I would rather write it in C syntax and
take advantage of the decades of tooling around C syntax. Cython is great and
an awesome community effort, but it still quite a simple compiler and has
limitations.

So far I have been talking only about ease of use, quality of programming
experience etc etc, but that is not the only issue here. The problem is calls
to C and more importantly callbacks from C to Python are expensive enough to
be non-ignorable. If you have a hot loop where you go back and forth between
C/Fortran world and Python thats going to incur a serious hit. The solution is
to make the containing piece of Code into C/Fortran/Cython, so it ends up
swallowing more and more of the application logic, leaving only but a shell of
I/O in the Python world.

Its not the end of the world but not quite the rosy picture you give. Another
issue is cultural, its common among many newer programmers not to have really
experienced fast runtimes, of course this is a generalization and does not
apply to all, but have seen it happen frequently enough. They are greatly
amazed by what I would call only modest improvement in runtimes and they would
be cheering "Wow! so speed much fast!" etc.

All of these make me be really hopeful about Julia. Interacting with the
community gives me the feeling that they get it. Julia is an expressive
language, already quite performant and not saddled by limitations of
vectorization. I do like the terseness of vectorized expressions over loops,
this is being filled by devectorize.jl. Yes there are more libraries available
in R or Scipy but given the ease with which one can code in Julia I dont see
this to be an unsurmountable problem. Every language has to begin somewhere
and unlike say other competing solutions like Torch7 I find the community very
friendly, responsive and pragmatic. It seems they spend conscious effort to
keep it that way. So, Julia community, here is wishing all the best.

I do love Python a lot, and I mean really really a whole lot (except for its
OOP parts) but this self cheering gets a little too much at times.

~~~
Derbasti
I have used CFFI in a few projects for writing a core computation in actual,
pure C, and dynamically calling it from Python. Performance is really great, I
vastly prefer it over Cython.

But, it doesn't solve the vectorization problem. Often times, you have to
transform simple iterative algorithms to a convoluted vectorized mess if you
want to have decent performance. Not every procedure is easily expressed as
matrix multiplication.

This is a very real cognitive tax of the vectorized approach. Thank you for
your writeup!

~~~
andreasvc
But why do you prefer it over Cython, since it can also wrap "actual, pure C,
and dynamically [call] it from Python"?

What is the vectorization problem? Both Cython and Julia allow you to write
tight loops and have them perform well.

~~~
Derbasti
In CFFI, you write either Python, or C. In Cython, you additionally write a
weird dialect that is neither C nor Python. I prefer straight C over Cython.

------
toleavetheman
My favorite change in 0.3 isn't even in the changelog:

Startup time has been massively improved. It used to take 5-10sec to start the
REPL or run a test, now it's about 0.2sec.

~~~
andrewflnr
Actually, that's the "system image caching" mentioned in item #1. :)

------
tapia
I gave julia a try some weeks ago, but it seems it has a big performance
problem when importing libraries... it takes too much time. This release
doesn't seem to solve this problem sadly :/

~~~
johnmyleswhite
Resolving this issue is one of the main goals for the 0.4 release. There is
already a way to get much better performance for frequently used packages, but
it involves a level of tinkering that's prohibitive for most users.

~~~
tapia
I'm glad to hear this! I'll be waiting for it to give it another try.

------
Stubb
Does redefining functions with dependencies in the REPL work with this
release? How about deleting items from the symbol table?

~~~
idunning
Is
[https://github.com/JuliaLang/julia/issues/265](https://github.com/JuliaLang/julia/issues/265)
the issue you are referring to? If so, not fixed.

Not sure about the second part, but `workspace()` was added in 0.3
([https://github.com/JuliaLang/julia/blob/release-0.3/NEWS.md](https://github.com/JuliaLang/julia/blob/release-0.3/NEWS.md),
[https://github.com/JuliaLang/julia/issues/1195](https://github.com/JuliaLang/julia/issues/1195))

~~~
Stubb
Yeah, that's the issue that I'm referring to.

Looks like workspace() wipes the whole slate clean. I was thinking along the
lines of R's rm() that can target individual variables.

------
beders
Has anyone spotted a buildpack for Heroku?

------
tomrod
Thanks for posting the release news!

