1. Readable code. Neither curly brackets and semicolons, those codependent blights on programmer productivity, nor bizarre unfamiliar syntax like Smalltalk.
   
   
2. Something like Ruby's blocks or Python's with - the cd function creates a context, as does the open function, and those contexts apply to the enclosed statements and are automatically cleaned up at the end. So the program changes its working directory to the data only for the code within the do...end block, without the programmer needing to worry about any details.

More significantly, while Julia is object-oriented, it is not class-based (as most object-oriented languages are). It uses multiple dispatch based on the arguments to a function rather than binding functions to an object.

That is, where in Python you might define an image object and a resize method, and call it like this:

In Julia you'd define the data structure of the object, and then define a set of functions that act upon that object. There might already be a resize function that acts on arrays or vectors or memory-mapped files (or a hundred other things), but when you call

Julia knows that you mean the image resize function, because it knows that the variable im is an image. Values cannot change their type, so the Julia compiler can bind to the right version of the function at compile time, unlike Python or Ruby, where dispatch is always dynamic.

And that matters because it means that Julia is about 20x faster than Python.*

What Julia doesn't (currently) provide is multi-threaded programming. It's supports coroutines, called tasks, that allow you to write your code in a logically multi-threaded way. And it supports message-passing multi-processing, so you can spin up multiple instances of your application on different CPUs and easily dispatch tasks to other workers and receive the results when they're done. But you can't have multiple processes sharing a common native data structure.

But then, neither (really) can Python or Ruby. Both support threading, but both have global interpreter locks - the infamous GIL in Python - that means that only one thread is working on native code or data structures at a time. Threads get unlocked when they are doing I/O, and in some C libraries, so you do get a speedup in real-world applications. So if all three languages are effectively still single-threaded, with threads largely a programming convenience, you'd go with the one that's 20x faster, yes?

Yes, except that Python has a huge and wonderful standard library and an even huger and wonderfuller ecosystem of third-party packages.

Except except:

1. You can embed Python in Julia, with two-way transfer of data and functions, using PyCall. You can just plain import your Python modules into a Julia program and use them:
   
   @pyimport pylab
   x = linspace(0,2*pi,1000); y = sin(3*x + 4*cos(2*x));
   pylab.plot(x, y; color="red", linewidth=2.0, linestyle="--")
   pylab.show()
   
   
   It's almost-but-not-quite Python on the Julia side (see the ; between the positional and named arguments in the pylab.plot call) but calling existing Python code from Julia is almost perfectly transparent.
   
   
2. You can access MongoDB from Julia. MongoDB isn't perfect** but it's the swiss-army chainsaw*** of NoSQL, at least since they fixed it so that it doesn't crash and destroy all your data every time a gnat sneezes.****
   
   
3. You can pretend it's Ruby and slap together web apps like there's no tomorrow using Morsel:
   
   using Morsel
   
   
   app = Morsel.app()
   
   
   route(app, GET | POST | PUT, "/") do req, res
       "This is the root"
   end
   
   
   get(app, "/about") do req, res
       "This app is running on Morsel"
   end
   
   
   start(app, 8000)
   
   
4. There's support for ZeroMQ, the lightweight queueing... Thing.
   
   
5. Also, Curl.

Full support for multi-threaded programming would make it even better, but since I don't really have that now, it's not a show-stopper. For mee.nu, I run five instances of Minx behind a load-balancing proxy, though we rarely need the performance. Julia provides plenty of ways to use multi-processor machines, just not that particular way.

And if it really delivers 10x the performance in practice, that's like getting 10-way multi-threading with zero software overheads and zero extra hardware.

So a cautious thumbs up so far from me.

* Or about 4x faster than PyPy, the Python JIT compiler. But since you can easily embed Python code in Julia (the PyCall package provides this) and PyPy still has a number of incompatibilities with common Python packages, there's an argument that Julia is a better way to go even for Python programmers.

1

I'm not sure I'd call Julia object-oriented, I'm not even sure I'd call it object-based (but I've really only dipped my toes into the documentation). It seems like someone got tired of Matlab's syntactic and semantic warts and interpretive performance* and decided to clean it up.  It's too bad SISAL never caught on.

* If the Matlab interpreter is where your code is spending most of its time, either you're doing it wrong** or you're using the wrong language...

** Ok, passing array arguments by value can be kind of expensive...

2 I'm not sure I'd call Python sane or healthy.  In fact, I'm pretty sure I'd call it a lot of four-letter words.  Which, actually, I do, fairly often, to the annoyance of my co-workers.

I'm nearing the point where I'm going to tell my boss that Python can go stuff itself, I'm retreating to c++.

3 C++?

It does depend on what you need to do, of course.  I have no love for C++, but there are plenty of tasks where it is the right choice and Python ain't.