If you're asking "why Julia versus other languages" it's that, well, Julia is fighting to answer that question for itself. As far as I can tell:
- Versus R and Octave: performance, coherent syntax, and more features for writing "programs" instead of just "scripts" - Versus Python + the Scipy stack: its scientific features are built into the language (instead of being an awkward layer on top of it) - Versus any proprietary platform (SAS, Matlab, etc): it's open source and free-as-in-beer, and therefore not confined to legacy/enterprise applications
I'm a data scientist and I currently use R and Python. I've been wanting to give Julia a try for months, and now that the ecosystem is starting to mature (plotting and data frames are must-haves for me) it's making more sense to spend some time with the language.
edit: looked up "call R from Julia", it looks like there's a n "RJulia" library for this. Assuming there's a Python equivalent? How does this compare to, say, using RPy2 in Python (which is nice but kind of annoying)?
You want RCall.jl and PyCall.jl. Both allow you to directly work with and manipulate native objects. RCall even allows you to bring up an R REPL.
Applause to the Julia contributors for their work on this innovative language with great out of the box support for modern computer chip architectures. However, they have fibbed to build up momentum, particularly their performance benchmarks. The tests are of compiled Julia with OpenBLAS for the benchmarks against out of the box versions of the other languages. Also, the benchmark code in other languages is with a style that is among the slowest implementations for each language. No seasoned programmer in any of those languages would write code in such a way.
It does seem that there is co-ordination to get Julia posts most attention, timing and upvoting.
Nonetheless, credit where it's due. It should become an awesome language, marketing hacks notwithstanding.
As for co-ordination on Julia posts - there is none. We submit all our blog posts to HN, and while some do reach the front page, many others do not.
Glad you like Julia and hope this helps.
Wonderful.
Insightful :)
It all depends on what you want to measure. The whole point of the micro-benchmark suite is to test very specific language primitives. I'd argue that the current set of benchmarks are more valuable for that than an "expert" implementation would be — that may end up simply testing the cleverness or resourcefulness of the expert.
1. https://github.com/JuliaLang/julia/blob/64409a0cae8b52d3f795...
Of course, such a benchmark it might not have the same marketing hue as claiming that Julia is 553 times faster than Matlab at parsing an integer, for example.
I'll mention multiple areas I think Julia excels. If you want to write quickly high performance numerical software then I don't see what the alternatives are.
It is the best language I've encountered for writing shell scripts. Bash is terrible due to the difficulty of factoring the code into functions and the frequency in which you forget to quote variables properly. Many end up thus using Python or Ruby. Ruby seems very popular, but Julia really works better. It has tighter integration with the shell and handles chaining, reading and writing to shell commands much nicer.
It also has all sorts of useful stuff ready to use out of the box and sane function names etc. I find it much more cumbersome to write shell scripts with python. Awkward to call processes. Got to always remember what every little module you got to import. Because of multiple dispatch, Julia allows much better naming of functions.
And as a computer language geek I love powerful LISP macros, but I can't get used to LISP syntax. Julia is the only language I know of which gives access to powerful macros and code generation similar to LISP.
As for your broader question, Julia definitely fills a gap that I have been pained by for years. I've used R since it was in beta, and it is slow, which is a pain when you are discussing numerical needs. Yes, you can program in something like C/C++, but that is painful because of its overhead and dependency complexity (although it's surprisingly become less painful over time). Python could be used too, and probably is better at this point in that regard, but it has many of the same problems as R.
Julia is open-source, fast, and well-thought out with regard to modern numerical programming problems. I can write something in Julia and it performs essentially as well as something in C, which is a huge time saver in multiple respects.
I do wish Julia were more general-purpose in its orientation, or that the solutions it offers were coming from a more general-purpose language, but at the moment that doesn't seem to be in the cards. Maybe as it grows it will find use as a more general-purpose language, which is possible; maybe as languages like Rust or Go grow they will occupy this niche as well. Rust is interesting to me in this way, but currently it has little to offer in terms of simplification over C++ for numerics, and Go is not friendly to numerics. I personally like Stanza, but it's in its infancy, and no one probably even knows what I'm talking about.
For whatever reason, my experience has been that numerical programming has been a kind of isolate in programming. Numerical computing has always seemed slightly neglected in programming languages, and languages that have targeted numerical computing have often never been able to shake the "domain specific" label. I've just sort of come to see it as part of the territory.
There's nothing wrong with Python, C, or R. Also, languages change rapidly, so who knows what will happen. At the moment, though, Julia offers the best of all three and the only big downside is lack of libraries, which is becoming less and less of an issue every day (I wouldn't say there's a lack of libraries, more that there's fewer libraries). So I think it's deserving of its current attention.
I guess the question is, why would a systems programmer use C, or a web programmer use Javascript, or a network infrastructure programmer use Erlang, etc. etc. etc.?