6 ms·

When out with friends recently, one of them mentioned how awesome Julia is. I was surprised to hear someone talk about it, even from another person in science.

When out with friends recently, one of them mentioned how awesome Julia is. I was surprised to hear someone talk about it, even from another person in science. She turned and gushed about how awesome it was, how supportive the community was, even though she was "not really someone who likes programming." And she liked it so much she was telling her friends about it at a bar! If you make a programming language that people who don't like programming love enough to spread by word of mouth when not near a computer, which technically-oriented people also love, that's a lot like the OSX terminal + nice GUI blend. That's a pretty rare thing. And for collaborative science it's pretty important. Often, you'll have people in a bio lab who are very proficient in their area of biological expertise, but who would be solving the wrong problem by spending 2 years trying to become C++ hackers. On the other hand, there are a lot of people who write computational libraries, but know they have to translate them to matlab, or write a matlab wrapper and pray that their users can get it to compile which might sound simple to folks here, but is really frustrating for less computationally oriented people when something goes wrong.

Pxtl 13y ago
To be fair, there's also Python+NumPy and R in that space, not just Matlab. Besides the "tinker with LLVM" thing, what does Julia offer that Python (or Cython for speed)+NumPy does not?
- smellelderberry 13y ago
  Julia has a community that doesn't feel threatened that their language is waning in popularity in some fields, and therefore doesn't feel the need to defend it every chance they get.
  - wirrbel 13y ago
    No need to make this personal. It was the original blog article that concentrated on the negative things and did not do a whole lot at explaining Julia's benefits. I really love Scipy and friends and I also think Julia is a promising system.
- 3JPLW 13y ago
  Everyone's answer to that question will be different. In my opinion, there's lots of things to love about Julia. First class arrays and array literals. It's a wonderful thing… like Matlab but very smartly designed. The type dispatch system makes so much sense for mathematical work. It's simply how math is done. And Stefan Karpinski (co-creator) often compares it to linguistic grammars, too, which may be a stretch but I think there's some truth to it. It just feels right. And it makes things very extensible, right down to the core language. And the core language is indeed mostly Julia itself. Compared to NumPy where things are often implemented in C or Cython. I've tried to hack on some Cython things in NumPy and was immediately turned off. It was so hard to debug and run interactively. Julia's interactivity is wonderful. The IJulia project brings over some of the best user experience of NumPy (in my opinion)… which is not NumPy but IPython. And the community is so very great and supporting. The package system is such a great asset and really lowers the bar to entry.
  - Toenex 13y ago
    Interesting that you mention IJulia. My concern with it is that when you are trying to develop a new technique or algorithm, the idea of introducing extra layers of code running in another system (in this case IPython) seems like a lot to deal with. Maybe I'm just a wimp ;)
    - 3JPLW 13y ago
      But it's not running through Python at all (as I understand it). The kernel is all implemented in Julia. It just uses the IPython frontend and architecture. See this post on the implementation of IHaskell[1] for more details. My understanding is that IJulia uses the same concepts. Notably, when running IJulia, you can't even use %%magics to change back to Python mode. 1. http://andrew.gibiansky.com/blog/ipython/ipython-kernels/ http://andrew.gibiansky.com/blog/ipython/ipython-kernels/ (Also, it's firmly endorsed by the language creators. Stefan recently gave a talk using IJulia).
      - Toenex 13y ago
        Thanks for the explanation and link. I think you are correct in that it doesn't appear to be using any Python. The demo I saw was given by Fernando Perez [http://www.youtube.com/watch?feature=player_embedded&v=F4rFuIb1Ie4 http://www.youtube.com/watch?feature=player_embedded&v=F4rFu...] where he demonstrated a cross language example which, whilst technically impressive, wasn't something I felt I would attempt. Like I said I'm probably just a wimp.
- Toenex 13y ago
  Agreed, Python with NumPy is definitely a key player in this space, probably more significant these days than Matlab. Don't forget Octave which continues to hold it's place as a Open Matlab compatible(ish) option. Whilst I'm a fan of R for experimentation and prototyping it is often let down by poor performance, particularly on matrix calculations. R's forte is really in providing reference implementations of an amazing array of statistical methods, often by the author of the technique. One of advantages of Julia touted by the authors is that much of the Julia system is written in the Julia language making it easy for users to understand many of the algorithms and contribute to the system. In practice I don't know how true that is (it seemed to spend a long time compiling C/C++ code when I last built it) but I can see the rationale.
- synparb 13y ago
  I remember there being talk of eventually being able to call Julia from within Python. I've also been quite happy using Numba as an alternative to Cython for some things when I need speed. It's a lot more light-weight with less boilerplate, although still a little rough around the edges.
  - dagw 13y ago
    I don't know about calling Julia from within Python, but you can call python from within Julia. This makes it very easy to wrap and use python libraries for things which Julia doesn't have good support for yet.
    - bayesianhorse 13y ago
      Would be awkward to run django from inside julia though...
  - jamesjporter 13y ago
    This already exists as a prototype as part of IJulia, see Leah Hanson's awesome blog post about it here: http://blog.leahhanson.us/julia-calling-python-calling-julia.html http://blog.leahhanson.us/julia-calling-python-calling-julia... The collaboration between the scientific Python and Julia communities in recent months has been awesome to watch.
- simonster 13y ago
  Writing fast code in Julia requires less effort than it does in Python or R. You don't have to drop down to Cython or Rcpp to get good performance. If you write an algorithm in Julia the same way you'd write it in C, it will achieve equal performance. If you write it the same way you'd write it in Python or R, it may not be optimal due to the cost of memory allocation, but it's still faster than Python or R. Julia is more concise than Python. The language was designed to work with multidimensional arrays; it wasn't bolted on afterwards. There is no difference between a 2D array and a matrix; * always does matrix multiplication and .* always does element-wise multiplication. There is no awkwardness involving differences between NumPy arrays and Python lists. Everything has a type, and you can make a multidimensional array that efficiently stores values of any type. You can define your own types and define how arithmetic operators act on them with a minimal amount of code. Julia's type system makes writing efficient algorithms easy without sacrificing any performance. If you define your own immutable type and define your own operators on it, Julia can make those operators run as fast as they would on ordinary values. In addition to general matrices, we have diagonal, symmetric, and tridiagonal matrices. The same routines that work on general matrices work on these as well with the same syntax, just more efficiently. Julia uses multiple dispatch instead of traditional class-based OO. Methods are not a part of the object; instead, they operate on the object. Different methods with the same name can be defined to work on different types, or a single method can operate on a set of types, but the functions it calls may be implemented differently for each of these types. This is a better fit for technical applications, where the data doesn't change much but the methods do. Julia is homoiconic, which is more useful than this article makes it seem :). It's easy to write code that writes code. If built-in language features aren't enough to get good performance with concise syntax, you can write a hygenic macro that does this for you.
  - wirrbel 13y ago
    To the rescue of numpy: A matrix from linear algebra and a 2D array are not exactly the same. In Python they are different convertible types and I think in practice it is hardly a drawback. That the multiplication operation is overloaded in the Mathematical World with the same symbol as the "normal" multiplication is unfortunate, numpys solution is as good as introducing two different operators (with one being an awkward .*) I love the multiple dispatch part about julia though. My fear however is, that unlike Python, Julia will lack enough libraries, especially on the unscientific part (GUI, databases, network, all the other stuff you need).
- blah32497 13y ago
  I used R day to day, but it's NOT as easy as MATLAB. There just isn't the same level of documentation and clarity.
- Stubb 13y ago
  Julia offers freedom from wondering whether you're betting on the wrong horse by coding for Python 2.7 or 3.x.
dnautics 13y ago
I had the opposite response, I played around with julia and found myself so frustrated I went back to octave. However, it was at an early stage of development and I bet there were a ton of bugs still around. I'll have to give it another shot.
- ihnorton 13y ago
  Do! The improvement over the past ~6 months has been staggering.
zhaodaxiong 13y ago
Julia is good, in ............ (10,000 words omitted) I think any serious programmer understand the importance of specifying context. For this article, the author should write: I dont care about type safety, security, etc, when I ......... (10,000 words). The title is flaming and shallow in any measure of programming language discussion...
- kazagistar 13y ago
  Um, you know that Julia has type annotations, right? They are optional, but if you are a shop that really really wants type safety, you can get it.

Pxtl 13y ago

To be fair, there's also Python+NumPy and R in that space, not just Matlab. Besides the "tinker with LLVM" thing, what does Julia offer that Python (or Cython for speed)+NumPy does not?

smellelderberry 13y ago
Julia has a community that doesn't feel threatened that their language is waning in popularity in some fields, and therefore doesn't feel the need to defend it every chance they get.
- wirrbel 13y ago
  No need to make this personal. It was the original blog article that concentrated on the negative things and did not do a whole lot at explaining Julia's benefits. I really love Scipy and friends and I also think Julia is a promising system.
3JPLW 13y ago
Everyone's answer to that question will be different. In my opinion, there's lots of things to love about Julia. First class arrays and array literals. It's a wonderful thing… like Matlab but very smartly designed. The type dispatch system makes so much sense for mathematical work. It's simply how math is done. And Stefan Karpinski (co-creator) often compares it to linguistic grammars, too, which may be a stretch but I think there's some truth to it. It just feels right. And it makes things very extensible, right down to the core language. And the core language is indeed mostly Julia itself. Compared to NumPy where things are often implemented in C or Cython. I've tried to hack on some Cython things in NumPy and was immediately turned off. It was so hard to debug and run interactively. Julia's interactivity is wonderful. The IJulia project brings over some of the best user experience of NumPy (in my opinion)… which is not NumPy but IPython. And the community is so very great and supporting. The package system is such a great asset and really lowers the bar to entry.
- Toenex 13y ago
  Interesting that you mention IJulia. My concern with it is that when you are trying to develop a new technique or algorithm, the idea of introducing extra layers of code running in another system (in this case IPython) seems like a lot to deal with. Maybe I'm just a wimp ;)
  - 3JPLW 13y ago
    But it's not running through Python at all (as I understand it). The kernel is all implemented in Julia. It just uses the IPython frontend and architecture. See this post on the implementation of IHaskell[1] for more details. My understanding is that IJulia uses the same concepts. Notably, when running IJulia, you can't even use %%magics to change back to Python mode. 1. http://andrew.gibiansky.com/blog/ipython/ipython-kernels/ http://andrew.gibiansky.com/blog/ipython/ipython-kernels/ (Also, it's firmly endorsed by the language creators. Stefan recently gave a talk using IJulia).
    - Toenex 13y ago
      Thanks for the explanation and link. I think you are correct in that it doesn't appear to be using any Python. The demo I saw was given by Fernando Perez [http://www.youtube.com/watch?feature=player_embedded&v=F4rFuIb1Ie4 http://www.youtube.com/watch?feature=player_embedded&v=F4rFu...] where he demonstrated a cross language example which, whilst technically impressive, wasn't something I felt I would attempt. Like I said I'm probably just a wimp.
Toenex 13y ago
Agreed, Python with NumPy is definitely a key player in this space, probably more significant these days than Matlab. Don't forget Octave which continues to hold it's place as a Open Matlab compatible(ish) option. Whilst I'm a fan of R for experimentation and prototyping it is often let down by poor performance, particularly on matrix calculations. R's forte is really in providing reference implementations of an amazing array of statistical methods, often by the author of the technique. One of advantages of Julia touted by the authors is that much of the Julia system is written in the Julia language making it easy for users to understand many of the algorithms and contribute to the system. In practice I don't know how true that is (it seemed to spend a long time compiling C/C++ code when I last built it) but I can see the rationale.
synparb 13y ago
I remember there being talk of eventually being able to call Julia from within Python. I've also been quite happy using Numba as an alternative to Cython for some things when I need speed. It's a lot more light-weight with less boilerplate, although still a little rough around the edges.
- dagw 13y ago
  I don't know about calling Julia from within Python, but you can call python from within Julia. This makes it very easy to wrap and use python libraries for things which Julia doesn't have good support for yet.
  - bayesianhorse 13y ago
    Would be awkward to run django from inside julia though...
- jamesjporter 13y ago
  This already exists as a prototype as part of IJulia, see Leah Hanson's awesome blog post about it here: http://blog.leahhanson.us/julia-calling-python-calling-julia.html http://blog.leahhanson.us/julia-calling-python-calling-julia... The collaboration between the scientific Python and Julia communities in recent months has been awesome to watch.
simonster 13y ago
Writing fast code in Julia requires less effort than it does in Python or R. You don't have to drop down to Cython or Rcpp to get good performance. If you write an algorithm in Julia the same way you'd write it in C, it will achieve equal performance. If you write it the same way you'd write it in Python or R, it may not be optimal due to the cost of memory allocation, but it's still faster than Python or R. Julia is more concise than Python. The language was designed to work with multidimensional arrays; it wasn't bolted on afterwards. There is no difference between a 2D array and a matrix; * always does matrix multiplication and .* always does element-wise multiplication. There is no awkwardness involving differences between NumPy arrays and Python lists. Everything has a type, and you can make a multidimensional array that efficiently stores values of any type. You can define your own types and define how arithmetic operators act on them with a minimal amount of code. Julia's type system makes writing efficient algorithms easy without sacrificing any performance. If you define your own immutable type and define your own operators on it, Julia can make those operators run as fast as they would on ordinary values. In addition to general matrices, we have diagonal, symmetric, and tridiagonal matrices. The same routines that work on general matrices work on these as well with the same syntax, just more efficiently. Julia uses multiple dispatch instead of traditional class-based OO. Methods are not a part of the object; instead, they operate on the object. Different methods with the same name can be defined to work on different types, or a single method can operate on a set of types, but the functions it calls may be implemented differently for each of these types. This is a better fit for technical applications, where the data doesn't change much but the methods do. Julia is homoiconic, which is more useful than this article makes it seem :). It's easy to write code that writes code. If built-in language features aren't enough to get good performance with concise syntax, you can write a hygenic macro that does this for you.
- wirrbel 13y ago
  To the rescue of numpy: A matrix from linear algebra and a 2D array are not exactly the same. In Python they are different convertible types and I think in practice it is hardly a drawback. That the multiplication operation is overloaded in the Mathematical World with the same symbol as the "normal" multiplication is unfortunate, numpys solution is as good as introducing two different operators (with one being an awkward .*) I love the multiple dispatch part about julia though. My fear however is, that unlike Python, Julia will lack enough libraries, especially on the unscientific part (GUI, databases, network, all the other stuff you need).
blah32497 13y ago
I used R day to day, but it's NOT as easy as MATLAB. There just isn't the same level of documentation and clarity.
Stubb 13y ago
Julia offers freedom from wondering whether you're betting on the wrong horse by coding for Python 2.7 or 3.x.

dnautics 13y ago

I had the opposite response, I played around with julia and found myself so frustrated I went back to octave. However, it was at an early stage of development and I bet there were a ton of bugs still around. I'll have to give it another shot.

ihnorton 13y ago
Do! The improvement over the past ~6 months has been staggering.

zhaodaxiong 13y ago

Julia is good, in ............ (10,000 words omitted) I think any serious programmer understand the importance of specifying context. For this article, the author should write: I dont care about type safety, security, etc, when I ......... (10,000 words). The title is flaming and shallow in any measure of programming language discussion...

kazagistar 13y ago
Um, you know that Julia has type annotations, right? They are optional, but if you are a shop that really really wants type safety, you can get it.