Why we created Julia - new language for fresh approach to technical computing

I wonder what they think about or have learned from <a href="http://en.wikipedia.org/wiki/Fortress_(programming_language)" rel="nofollow">http://en.wikipedia.org/wiki/Fortress_(programming_language)</a> , another recent-ish attempt to deliver a modern and powerful scientific programming language.<p>Personally I'm a little wary of being ghettoised into something overly domain-specific for scientific/numerical computing. Really good interop may mitigate that -- something which can navigate the unholy mix of C, C++, fortran, matlab, octave, R and python routines one comes across trying to reproduce others research work, would indeed be awesome.<p>I do wonder if some of the noble demands of this project might be better delegated to library developers though, after adding a bare minimum of syntax and feature support to a powerful general-purpose language. For now Python+numpy+scipy seems a great 90% solution here.

Much praise!! These guys have incredibly good taste. Almost every single thing I can think of that I want in a programming language, they have it. All in the one language!<p>The fact that it has parametric types, parametric polymorphism, macros, performance almost as good as C, good C/Fortran interop, 64 bit integers and an interactive REPL all in the one language just blows my mind.<p>I wasn't able to tell if it is possible to overload operators, which is another thing essential to mathematical code.<p>I was also unsure why the keyword end was needed at the end of code blocks. It seems that indentation could take care of that.<p>I also didn't see bignums as a default type (though you can use an external library to get them).<p>However, all in all, I think this is the first 21st Century language and find it very exciting!

Just spent the last hour reading through the docs and playing around with it. This is some damn sexy stuff. It's been a long time since I've been this excited by a language.

The language looks interesting, but I am a bit concerned about the license situation, as in my understanding they have misinterpreted the GPL with regard to shared libraries. Quoting:<p><i>Various libraries used by the Julia environment include their own licenses such as the GPL, LGPL, and BSD (therefore the environment, which consists of the language, user interfaces, and libraries, is under the GPL). Core functionality is included in a shared library, so users can easily and legally combine Julia with their own C/Fortran code or proprietary third-party libraries.</i><p>The FSF disagrees (<a href="http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins" rel="nofollow">http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins</a>):<p><i>If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when the main program is distributed for use with these plug-ins.</i>

Looks very much like a python without the legacy and a touch of ruby, ipython as the default shell, better multiprocessing, better os/system access, decorators and mathematics. Nice clear documentation too.<p>Given how similar to python they are their main competitor is pypy, which isn't too far behind them in performance I'd suspect (absent from the benchmarks though). I was fully expecting someone to make a non-compatible fork of pypy to create a faster python-like lang/something like julia. They should quickly get some elegant small libraries like sinatra/bottle and requests (access to dbs with http interfaces as well). A robust requests+lxml library built-in would be simply amazing.

Awesome stuff: <a href="http://julialang.org/manual/metaprogramming/" rel="nofollow">http://julialang.org/manual/metaprogramming/</a>

It's not yet another language that we need. It's more high level functions.<p>C or fortran can be as fast as they want, but in mathematica I can do MorphologicalComponents[] and get the components. having these functions available to me speeds up my time to discovery by 1000x or more.

Pardon the possible naïveté, but I'm so old I remember Ada. Seems that language was designed to address a very similar problem space. What does Julia offer that Ada doesn't? Or perhaps: why is ada so deficient that spending 2+ years inventing a new language was a better proposition than taking the time to improve Ada?

I have made the same rants about numeric computing language issues as the Julia creators. I would avidly adopt Julia based on the documentation on the website. It seems to me that this is a beautifully conceived language given the concerns it attempts to address. Amazing even if the performance never improves.<p>The R thread on the dev list gives an accurate representation of the obstacles to Julia being widely adopted, however. One might become very unhappy while using R, but sometimes you have to use it, because something you want is only in R, due to the ubiquity of that tool for stats.<p>If Python, which does not have that many disadvantages besides not having been explicitly designed to appeal to users like me, cannot unseat Matlab and R, Julia will have a difficult time.<p>But I will give it a try, and will implement some simple but core algorithms that I use a lot.<p>Another idea to test Julia's usefulness would be to port a tool like Waffles to Julia. In my opinion implementing such a sensible tool like Waffles in C++ is a heartbreak.

I'm a little worried about some of those benchmarks. They appear to have benchmarked R from a few years back against 2011 Matlab, for instance. In addition, they provide no code used for the benchmarks. That being said, this looks really interesting, and I'm gonna bookmark it for when I have time to examine it properly (after the damn phd is finally submitted).

This looks like it would be a great language to tackle the Project Euler problems with - which is usually a good sign, in my book. A big-int type would be nice though.

So, the usual caveats about writing code to match the languages strengths apply here. For example the fib function plays to a python weakness - function overhead. Rewriting the code to be a simple loop removes the inefficiency:<p><pre><code> import time def fib(n): if n &#60; 1: return None if n == 1: return 0 if n == 2: return 1 x0 = 0 x1 = 1 for m in range(2,n): x = x0 + x1 x0 = x1 x1 = x return x if __name__=="__main__": assert fib(21) == 6765 tmin = float('inf') for i in xrange(5): t = time.time() f = fib(20) t = time.time()-t if t &#60; tmin: tmin = t print str(tmin*1000)</code></pre>

this is surprisingly complete for a relatively new(?) project.<p>one notable restriction is that inheritance is only for interface, not implementation.<p>also, can anyone find a sequence abstraction (like lists)? arrays seem to be fixed size and i don't see anything else apart from coroutines. am i missing something?!<p>[perhaps not, if it's intended for numerical work. on reflection i am moving more and more towards generators (in python) and iterables (in java, using the guava iterables library to construct maps, filters etc) rather than variable length collections, so maybe this is not such a big deal. it's effectively how clojure operates, too...]

Nice! I do a fair amount of scientific computing in MATLAB. This looks to have a lot of the powerful array syntax / functions of MATLAB, but with the neat feel of Python, and all kinds of extras.

When you try to install julia on MacOS X 10.7.3, you may see the make fail because wget is not installed. Easy to fix with:<p>brew install wget<p>[Edit] git page says gfortran (and wget) are downloaded and compiled, but if they're not already installed make fails. So...<p>brew install gfortran<p>The need to do this separately may have to do with licensing?<p>[Edit] And if you're not root, install to /usr/share/julia will fail. So you'll need to do:<p>sudo make install<p>I'm sure all this is perfectly obvious to Unix-heads who are inured to this sort of abuse, but I'm a Mac-head, used to things that Just Work, and I hate this shit.

Slightly off topic, but V8's benchmarks really surprised me

Pretty tied into Python/Numpy ecosystem &#38; 3rd party libs; however, after reading that (somewhat over the top, albeit very persuasive) posting, I'm definitely going to dig a bit deeper. Really nice first impression, especially like the clean syntax and calling of c -- looks promising, thanks!

I am currently building it - OS X Lion. First, I had to install wget:) Then, I got a certificate error on the https, so I pasted the command into Firefox and got the tarball. After copying it to the julia dir, I edited the tar command and ran it. Finally, doing make right now.<p>Here is the certificate error: Connecting to github.com (github.com)|207.97.227.239|:443... connected. ERROR: The certificate of `github.com' is not trusted. ERROR: The certificate of `github.com' hasn't got a known issuer.

Very exciting. The real power of MATLAB likes in its toolboxes, though, I wonder if there will be an easy (and possibly automatic) way to convert toolboxes.<p>One more thing: it would be awesome if the `manipulate` from Mathematica could be incorporated somehow in that web interface. See:<p><a href="http://www.wolfram.com/broadcast/videos/manipulate/" rel="nofollow">http://www.wolfram.com/broadcast/videos/manipulate/</a>

Would be interesting to see how Julia perf compares to C++ compiled or JITed with LLVM via G++ 4.6+Dragonegg or Clang 3.0/svn. Would be more apples-to-apples, since both would use the same middle- and back-end. G++ 4.2.1 is a bit obsolete at this point, but as it probably came by default on the MBP they tested on, it's understandable.

For analogy there are few original liquor (vodka,rum,Whiskey,Brandy,Wine etc..) but god damn so many cocktails, so many cocktails.<p>Same in Programming Language design. Few original concepts, Lisp,C,Smalltalk, but so many cocktails even my grandma is creating one. All we want is more libraries.

I'm more concerned with visualizing the data than with compiler optimizations or types/operators.<p>I see that d3.js is included in the package, but a cursory glance at the docs and I didn't see any examples of how to generate a chart.

I hope this really takes off. Though, for it to really take off it needs a large ecosystem. The fact that the source is hosted on Github is a good start.

If you look at the Github repo, you will notice the second most used programming language in the repo (C being the first) is Objective-J ! I wonder why?

This is very exciting - congratulations on the launch of Julia. Now good luck as you move towards building a strong community!

Anyone else having compile issues? I'm on Ubuntu 11.10 (Server x64) and make fails consistently.

a bit late to the party here, but i see no-one has mentioned gpus. since julia supports calling c libraries i guess this will work, but i wondered if anyone knew of any work on closer integration?<p>(also, julia is not a great name for googling....)

Is Julia homoiconic? Could someone give an example of a Julia macro?

Their site seems to be taking a hammering. Any mirrors?

How does one open up a socket in Julia?

Do you also want ice cream on top?

awesome language but the manual need some works in user-friendliness

Congrats! Great job!!

And the moon on a stick :-) Not sure many "technical" programmers would take c as the desert island programing language.<p>Sound interesting though if it can make hadoop easier to use id take that as win I dont think its going to replace fortran as a HPC language.

They want something like OCaml ...

No Windows support, really ?!

Obligatory xkcd: <a href="http://xkcd.com/927/" rel="nofollow">http://xkcd.com/927/</a><p>It's about standards, but it still applies.