
Julia, the One Programming Language to Rule Them All - luu
http://www.wired.com/wiredenterprise/2014/02/julia
======
StefanKarpinski
I'm dismayed that this article portrays Julia so much as _my_ creation and
downplays the roles of Jeff and Viral – if anyone deserves the lion's share of
the credit for the language, it's Jeff. I'm guessing this happened because I
had a publication-quality photo available for use and told a relatable
narrative in the interview we did, whereas Jeff stuck somewhat more to
technical matters.

Oh, and Julia 1.0 hasn't been released yet. We're currently working on 0.3,
which should be out in about a month.

~~~
bjz_
The "One Programming Language to Rule Them All" headline was pretty horrible
too. I don't hold it against you though, – Julia is an exciting language and I
really hope you guys do well.

~~~
CatMtKing
I think it was a poor interpretation of: a single language that is good for
prototyping and also good for writing performant code.

------
gfodor
The main dynamic this article basically fails to describe clearly is that the
status quo for scientific computing is that you do your nice, high level
modeling in MATLAB or R, and then when you get good results, you port it over
to C/C++/Java for production. It's usually a write-only process since the code
you end up with in Java for example completely obfuscates the clean algorithm
you designed in MATLAB. Julia's core value proposition (if I understand it
correctly) is that you can build your models and algorithms in a MATLAB-like
environment (with macros!) and then, lo and behold, you can actually just tune
and deploy this code right where it is, without having to do a port.

~~~
blah32497
(Note: I haven't tried Julia yet)

This would save so many man hours... At my shop, for every MATLAB engineer
(mostly older guys) you need a C++ guru (mostly younger guys) to translate his
stuff into something that will run fast.

On the other hand having seen the code the MATLAB folks write... I'd be
worried. It's possible to write MATLAB in a way that is clean and makes the
core algorithm presentable but that's rarely a priority. The real advantage of
MATLAB is the quick development cycle. With the right packages you can make
C++ look comparable... sorta.

Fundamentally the problem with MATLAB engineers is that they don't understand
how to optimize code b/c they don't understand what's going on under the hood
and they don't understand how to organize code b/c they don't have a concept
of object oriented development, writing to interfaces, design patterns etc.
etc.

EDIT: Just to clarify, I don't mean to denigrate MATLAB engineers. I'm just
saying that in the current system you have two groups that specialize in
different things. One focuses on algorithm development, and one on
programming. I'm just speculating that maybe there is a good reason for it,
and it may be unreasonable to ask one person to do both.

~~~
StefanKarpinski
This is why one of the design goals of Julia is to have a fairly transparent
performance model. In particular, if you write C-like code, you get C-like
performance. A lot of the most twisted and impenetrable Matlab code exists
because Matlab forces you to vectorize _everything_ to get acceptable
performance. Generic programming and design are also very important in Julia.
It takes a while to get the hang of it, but people do seem to after a little
bit.

~~~
Beliavsky
Fortran 90 and later versions of Fortran have array operations, as in Matlab,
but you can also write loops and have the compiler optimize the code. There
already is a high-level language for scientific computing with C-like
performance.

~~~
m_mueller
People often sneer at Fortran, but there's a lot that can be done with it in
scientific computing, including very performant GPGPU computing. That being
said, the dream of having a matlab like prototyping environment directly
result in production level HPC code is probably never going to be realised in
Fortran - maybe Julia will get there? All I can say is that the tooling needs
to be top notch for that to happen and the performance can't just be in the
order of magnitude of Fortran/C - it needs to be within 20% or so. Once you
run software on clusters that cost millions, programmer time becomes rather
cheap, especially in academic settings.

------
foldor
Sounds like a fluff piece. It first tells us that this language is the "One
Programming Language to Rule Them All", but then it adds:

> "That said, it isn’t for everyone. Bezanson says it’s not exactly ideal for
> building desktop applications or operating systems, and though you can use
> it for web programming, it’s better suited to technical computing.".

So what is it? Is this the supposed "One true language", or is it just another
language with a narrow scientific focus?

~~~
idunning
I'd agree about it being a fluff piece, although I think the binary options
you present aren't fair.

I'm not a core developer on Julia, just a user and package creator. It is
geared towards technical/scientific computing, and excels in that task - it
has replaced the combination of Python and C++ I used previously. I think what
Jeff Bezanson is saying is that there is nothing intrinsically unsuited about
Julia for doing web programming or desktop applications. It benefits from a
fresh start in this respect, and also by using best-of-breed libraries from
OpenBLAS to libuv. This is in contrast to other languages for technical
computing like MATLAB or R which I wouldn't consider to be practical choices
for making, for example, a math-as-a-service application (although R is
getting into this territory with things like shiny).

------
evmar
After all the Julia hype on HN I thought I'd try it out.

I was surprised to discover how slow it actually is to use. Here's a quick
demo of booting up the Julia repl with two libraries loaded and then
immediately exiting:

    
    
        $ time julia -e 'using Distributions; using Gadfly; exit()'
        real	0m22.778s
    

With behavior like that it's not going to replace R as my go-to tool for
graphically exploring data.

I'm sure they'll improve this eventually. Much like with Rust, my hopes are
high. But also much like with Rust, I wish the hype came after the promises
were met.

PS: this article claims that Julia 1.0 was released in 2012, but as best as I
can tell the most recent code you can get calls itself 0.3. The above was with
Version 0.3.0-prerelease+1174 (2014-01-23 16:58 UTC).

~~~
StefanKarpinski
You literally picked the single package that loads the most other packages.
Clearly this needs work, but just running vanilla julia without loading
packages is not bad at all these days:

    
    
        $ time julia -e 'println("Hello, world.")'
        Hello, world.
    
        real    0m0.209s
        user    0m0.299s
        sys     0m0.104s
    

Julia now pre-compiles the jitted code for it's base system, and the plan is
to allow the same thing for packages. As others have noted, starting up Matlab
is extremely slow and starting up a full R environment isn't all that fast
either, nor is starting a JVM all that speedy. Startup time alone doesn't
prevent a system from being useful.

~~~
evmar
Thanks for replying! I didn't anticipate that my comment would generate so
much controversy. :( I was only relating my own experience in trying out the
tool, and comparing it to the tool I currently use frequently despite not
liking its semantics very much: R.

When I had encountered the slowness I was complaining about above, I poked
around online and saw that you all were certainly aware of it and had plans to
improve it. I think I even downloaded a 0.2 binary and then tried out trunk to
see if it had already improved. All I had meant to say was (like Rust) that I
anticipate I'll need to wait for a more complete version.

------
aldanor
1) "Ruby and Python are good general purpose languages, beloved by web
developers because they make coding faster and easier. But they don’t run as
quickly as languages like C and Java." \--- sorry to spoil the party but NumPy
is quite a bit faster than Julia in real-world applications. Something as
trivial as summing elements of an array runs much slower in Julia (unless they
fixed it, last I checked was about 4 months ago). I'm not even gonna get
started on pypy / llvmpy / numba / cython. R, albeit being a horrendous
language, can be hardly beaten by anything at the moment due to its epic
plotting tools like ggplot2 and the sheer amount of statistical packages
created by scientists from all over the world; it's like github for many of
the stats guys. Except unlike github, most of the packages are not open-source
and hence can't be directly ported to python/julia/whatever..

2) Lack of existing infrastructure for scientists and general purpose stuff
like various SQL adapters and bindings. Take any data-oriented/scientific
field, there's gonna be a python library or a c++ library with python bindings
for it. Data munging? pandas. Plotting? matplotlib. Machine learning? scikit-
learn. MC Monte-Carlo? PyMC or PySTAN. Optimization? scipy. That's just to
name a few... those are all huge libraries with many thousands commits in
their repos and many thousands human hours behind them -- it will be pretty
hard for anyone to catch up fast. /* it's worth mentioning here though that
many libraries in scientific Python stack were developed by aggravated R /
Matlab users who loved the tools but hated the language => matplotlib/pyplot
was initially a direct port of Matlab's plotting tools, pandas was initially a
direct port of R's data.frame, etc _/

3) 1-based indexing. Seriously, wtf? /_ insert an arbitrary Dijkstra joke here
*/

Not trying to bash Julia deliberately but I'd say by publishing a fluff piece
like this Wired in fact discredits the Julia community who are nice and
enthusiastic folks.

~~~
simonster
1) is probably still true at the moment as long as you really need that large
array, but the performance gap is likely to disappear once we have better
garbage collection and SIMD support, which are both open pull requests. On the
other hand, if your algorithm can be expressed in a loop that touches less
memory, in my experience, devectorized code in Julia beats vectorized code in
NumPy or MATLAB, and absolutely destroys devectorized code in those languages.
This is vitally important in my work, since the data sets I work with are so
large that expressing the algorithm in terms of vector operations would
require more memory than my computer actually has (and it has 64 GB of
memory).

Numba and especially cython are bolted on hacks to deal with the poor
performance of the interpreter. They are not conducive to the kind of
modularity you can get with Julia or plain Python, and they have their own set
of rules for achieving high performance. Their main upside is that, as you say
below, people already have a lot of Python code, but if you were starting from
scratch you would probably not design them into the language. NumPyPy still
doesn't implement all of NumPy, although I think it's been under development
for roughly as long as Julia.

2) would be a problem for any new language, but it is partially mitigated by
the PyCall package, which makes it easy to call almost any Python code from
Julia. There are even Julia wrappers on top of pandas and matplotlib that
allow you to use them while following standard Julia programming conventions.
I've played around with calling PySTAN from Julia, and it's not substantially
harder than calling PySTAN from Python.

~~~
sixbrx
> __once we have better garbage collection __

IMO the importance of the garbage collector needs to be underscored.

My experience with Julia was that if I pre-allocated arrays and wrote in a low
level like (C-like) way, then it would be fairly fast (also, need to avoid
closures but that's another issue).

If, however, I generated any new values inside loops (and using proper
abstractions, this is hard to avoid), then garbage collection would often
massively slow down computations and make performance hard to predict.

Unfortunately, I think having a truly high performance garbage collector is a
massive undertaking. I hope I'm wrong about that.

~~~
simonster
See
[https://github.com/JuliaLang/julia/pull/5227](https://github.com/JuliaLang/julia/pull/5227)
for the open PR. The benchmark there suggests 2-3x improvement. There is a
decent amount of low-hanging fruit, although "truly high performance garbage
collection" means different things for different applications and LLVM is
apparently not a good platform for generational GC.

There are further possible improvements that are not strictly related to GC.
We could determine that an array of the same size is being created on every
iteration of the loop and allocate that memory only once. Ideally we'd
automatically devectorize code to remove temporaries, but that is quite hard.

------
pmr_
> "What we need, Karpinski realized after struggling to build his network
> simulation tool, is a single language that does everything well."

and later:

> "Bezanson says it’s not exactly ideal for building desktop applications or
> operating systems, and though you can use it for web programming, it’s
> better suited to technical computing."

So, Julia is not what we need? ;)

Besides this contradiction I'm not entirely convinced that we need one
language to rule them all. I'm not even sure I want multi-paradigm languages
(C++ anyone?).

Aren't the problems explained in the introduction of this article not caused
by the tools instead of the programming languages? I don't see how using
multiple languages complicates patching (unless the article is talking about
monkey patching which I doubt), but I would understand how going through 4
different debuggers could drive you crazy.

Disclaimer: I'm not familiar with Julia and I will not judge it based on a
Wired article.

~~~
john_b
> _What we need, Karpinski realized after struggling to build his network
> simulation tool, is a single language that does everything well._

That wasn't quoted in the article, so I'm assuming it was the author's words,
not Karpinski's. The Julia devs seem to be more interested in solving the
(prototype) -> (translate to low level language) -> (optimize for production)
inefficiency rather than making one language to solve every conceivable
problem.

------
moron4hire
Me reading the Julia documentation: "Interesting... hmm, don't quite
understand that, but moving on... oh that's neat... wait, arrays are
1-indexed, not 0-indexed? ABORT!"

EDIT: and I consider this to be all the proof I ever need:
[http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EW...](http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html)

~~~
silentbicycle
You might want to read this, then:
[http://exple.tive.org/blarg/2013/10/22/citation-
needed/](http://exple.tive.org/blarg/2013/10/22/citation-needed/)

~~~
mcguire
And, once again,

" _And that’s the most coherent argument I can find; there are dozens of other
arguments for zero-indexing involving 'natural numbers' or 'elegance'[2] or
some other unresearched hippie voodoo nonsense that are either wrong or too
dumb to rise to the level of wrong._"

I still believe this is the only time EWD's work has ever been referred to as
"unresearched hippie voodoo nonsense".

Is this the same Mike Hoye who hacks Zelda?[potato]

[potato] [http://www.huffingtonpost.com/2012/11/16/mike-hoye-hacks-
zel...](http://www.huffingtonpost.com/2012/11/16/mike-hoye-hacks-zelda-
vid_n_2140509.html)

[2]
[http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EW...](http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html)

------
Fixnum
Julia seems nice, but the fact that the developers don't care about TCO is
annoying and vaguely reminiscent of Python. If this were added, not only would
many algorithms become more natural to express, but it'd go to the top of my
list as a recommended first language (instead of Scheme or Lua).

------
riggins
Wasn't one of Bjarne Stroustrup's reasons for building c++ to make the network
simulations he was working on more tractable?

------
vezzy-fnord
More clickbait and erroneous reporting from Wired. Typically, I stay away from
most of their articles, besides the _Threat Level_ column, which actually
hosts engaging pieces of journalism.

------
cabinpark
I keep seeing Julia promoted as the grand new language but honestly, I am
incredibly sceptical. Working in the scientific programming community, I am
keenly aware at how slow things move. In only the last few years have I seen a
push towards even using Python as a viable scientific tool. The problem is
that science moves slow and, for the most part, scientists aren't interested
in the programming aspect too much, but getting the results. They have one
system that works and they stick with it.

One problem, that I don't see mentioned, is that verification of correctness.
There is a reason people use decades old packages and code: they know that the
tool is reliable and correct. My supervisor's code is based off his
supervisor's code, which has been around since the 80s. At least 50+ papers
have been published based off this specific code so we know that it is
correct. The amount of time it would take to re-write and test the code
written in a new language would be a very large times-sync that no one wants
to do because they could spend that time doing research. I think this is part
of the reason why things change slowly in the scientific computing community
as whole. There have been tens of thousands of papers published that use
Fortran/C/C++/Matlab and this new kid Julia comes along and how many
scientific papers have been published using Julia code? I would imagine barely
even a fraction. To scientists, this is reason to be sceptical. I'm not saying
I agree with this but it is how scientific computing does think.

Also, on a personal note, the marketing needs to change. Since of the creators
is reading this, if you want get the scientists, drop the grandiose claims of
"one language to rule them all", although that's probably not your fault. To
me, I immediately smell bullshit a mile away when I hear that. Too many times
in the history of scientific programming languages have people made similar
types of claims only to see it crash and burn. This is why many the older
folks won't bother.

Reading Julia's homepage, I would be unconvinced about why I should choose
Julia over Matlab. Heck, why not use Python? Python is open source and has
been around a lot longer and people have certainly of that.

Also your speed tests, well fix them. For example Matlab vs Julia. Calculating
the Fibonacci numbers? Honestly who cares. Plus why are you even computing
them recursively, that's a silly way to do it. I understand it demonstrates
recursion, but it's a pretty useless thing in my opinion. I only ever see the
Fibonacci numbers come up in programming contest problems. I can honestly say
I've never seen them used in real applications that scientists do. And if they
were you would never implement them this way. Also the implementation of
quicksort, why did you write your own? Use the built-in one for a more fair
comparison. No one writes their own sorting algorithm but uses the built-in
languages ones. Do that here. It is disingenuous to Matlab to not use the
built-in functions.

The real tests that I would care about would be the random matrix
multiplication. That's something that is way more common than calculating
Fibonacci numbers. And here Julia is a little faster than Matlab but not too
much. I'd be sceptical of why I should switch. Similarly a single number tells
me nothing. Just because it says Julia is faster, well that's one test. How
well does Julia scale? Is it true that Julia is faster than Matlab for
multiplying NxN random matrices? How well does this scale? A single test tells
me nothing. I'm obviously bias towards matrix tests since my research used a
lot of matrix operations, but if you read papers about various codes they
almost always include scale tests. This is what my colleagues would care about
more than anything since they have massive datasets so scalability is
critical. Remember you are trying to sell this to scientists who are,
obviously, scientists, so having good quality data to show them is critical. I
discussed Julia with my colleagues and this was one of the things we
immediately mentioned. The tests shown didn't convince us at all that it was
even worth considering.

Plus, I'll be honest, I feel the homepage is marketed more towards computer
scientists than numerical scientists. The first feature is "Multiple dispatch:
providing ability to define function behavior across many combinations of
argument types". The hell is that? Why do I care? Remember who your audience
is! To give you an example, I will tell you about my office mate. He is a PhD
student working on turbulence and uses Matlab for all his data processing
afterwards. His code comes from simulations written in Fortran that run on the
local supercomputing cluster. They are stored in the NetCDF format. After the
simulations are done, he opens up Matlab, reads in the NetCDF file and runs a
bunch of data-processing functions to compute various quantities from the raw
data. He then plots these things. On the Julia homepage I don't even know if
Julia can even do graphics. Can it? If it can, the homepage doesn't mention
any plotting libraries. So, I repeat, what exactly does multiple dispatch mean
and why is it so important? If you want him to be using Julia, then you need
to explain to him why he should be using it over Matlab. Look at the numpy
homepage. It is short and to the point. Plus it has a nice link to "NumPy for
Matlab users" which is something I would want to know immediately. Julia, as
far as I can tell, you have to go to docs, Julia manual, Noteworthy
differences from other languages (which is at the bottom of the screen!!).

I could probably come up with more criticisms and suggestions but I don't want
to write a book. I should say, I completely and fully support what Julia is
trying to achieve. I find that Python is just too awkward to be a good Matlab
replacement. To me, Python is a very general tool that also has the ability to
do similar things to Matlab. However since Matlab is designed to do numerical
computing, and Python isn't, I find Python to be awkward for some things. But,
at least it can run on the computing clusters. Matlab is stupid with licensing
and trying to get it to run on the supercomputing clusters is near impossible.
Definitely in the future I am going to try Julia as a data-processing step
since it is free and open-source and not subject to any of that licensing
crap. Plus the parallel aspect interests me although I have no idea how good
it is since I don't see any graphs showing what sorts of advantages I might
get. Plus the documentation page is rather dense text-wise and not that
appealing to read right now.

But, I think the tl;dr is that remember who you are marketing to. Remember
that scientific computing moves slow. I know colleagues who have just
discovered version control and think it's amazing.

~~~
Stubb
Why not use Python? Do you mean Python 2.7 or Python 3.x?

Multiple dispatch lets the user define several functions with the same name
and have the compiler pick the right one based on the arguments. For example,
you could have three versions of the foo() function, one for reals, another
for complex, and a third for matrices. You could define your own types and
write additional versions of foo()—the compiler will pick the right one based
on the underlying types. Julia's type system makes a lot of sense once you've
gotten the hang of it.

I'd suggest fiddling with Julia if you have some time, as I think it rolls
together some good ideas. But it still has a way to go IMHO. Redefining
functions with dependencies in the interactive toplevel doesn't work quite
right, and you can't delete entries from the symbol table. It concerns me that
these things don't work. I figure that I'll give it another look as a tool for
serious work when 1.0 gets released.

I'll stick with R in the mean time—less change of unpleasant surprises. But I
could see Julia replacing R for me in a few years if it's done right.

~~~
cabinpark
I'll admit that is an interesting feature honestly the first thing on the
list? It's certainly a cool and interesting idea, but I'll admit it's not a
super important feature in my view. Thinking back on all the research I've
done I can't think of a single time where I would need such a feature. I never
use any data strucures beyond matrices, which Matlab handles by default. Since
1x1 matrices are just numbers, every function that works for matrices, works
for single numbers.

I do use Python, but it came into it late on my project. Future projects will
definitely use Python since it's good enough for data processing stuff. Hard
core numerics will still be done in Fortran/C.

I definitely do see Julia being the better version of Matlab but it certainly
has a ways to go.

------
bradenb
Working for a small company that does a lot of parallel combustion CFD
modeling and simulation, I'd love to see our engineers try out Julia and see
how it much easier it could be on them.

But, from my experience trying to establish rules for using version control, I
also realize that they're unlikely to ever rewrite (or even modularlize) their
codebase to take advantage of any other language.

------
sriram_sun
FTA: "Julia is also designed parallelism." Did the author even proofread the
article?

------
malisper
I'm guessing the best predictor of whether Julia will be the "one language to
rule them all", is the difficulty of writing macros in it. If they somehow
figured out a way to make writing lisp-like macros in a language with infix
notation easy, Julia will easily become the next big thing. Otherwise I would
have to say that the trade offs between syntax and macros would make lisp a
better choice (see pg's argument for lisp macros[1]).

For someone who has used both Julia and lisp macros, how do they compare?

[1] [http://www.paulgraham.com/avg.html](http://www.paulgraham.com/avg.html)

------
ctdonath
Way back in the heyday of Byte magazine, I recall ads for the pending release
of The Last One, a programming language to end all programming languages. Once
released, it disappeared. (Anyone remember it?)

------
leobelle
Is it easy to create non-blocking TLS socket connections with Julia? How about
making an HTTPS request? If Julia has async operations, are they inline,
promises, events or callbacks?

~~~
KenoFischer
Yes, actually, this is quite easy. Basically the I/O model uses cooperative
coroutines. For TLS, you'll want to look at
[https://github.com/loladiro/GnuTLS.jl](https://github.com/loladiro/GnuTLS.jl).
Then, after setting up the stream with the underlying socket, protocol
information, etc. (see the README for how to specify this), you can just use
it as any other IO stream...

    
    
        # Set up stream `sock` here
        @async begin
            println(sock,"Hello World")
            line = readline(sock)
            println(sock,"You typed ",line)
        end
    

Basically the encryption happens on the fly and the stream can be used just
like any other socket. For example, in the http client code here:
[https://github.com/loladiro/Requests.jl/blob/master/src/Requ...](https://github.com/loladiro/Requests.jl/blob/master/src/Requests.jl#L197-L204),
the only difference between HTTP and HTTPS is how the socket is set up, the
actual reading and writing is the same. Hope that helps!

------
dzink
I got to play with Julia at the UChicago workshop. Good stuff, especially if
you want to move away from MATLAB.

------
taylodl
_The one programming language to rule them all that isn 't for everyone._

I had to laugh at the irony of the juxtaposition of the title and the final
sentiment! I like languages so I'll definitely be checking out Julia.

------
ryangripp
[http://xkcd.com/927/](http://xkcd.com/927/)

------
joesmo
The article contradicts itself resulting in nothing more than a silly,
uninformed rant.

If:

"Together they fashioned a general purpose programming language that was also
suited to advanced mathematics and statistics and could run at speeds rivaling
C, the granddaddy of the programming world."

Then:

"That said, it isn’t for everyone. Bezanson says it’s not exactly ideal for
building desktop applications or operating systems, and though you can use it
for web programming, it’s better suited to technical computing."

does not follow based on the definition of "general purpose."

