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.
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.
I huge part of the goal here is to reduce the need for the "unholy mix of C, C++, fortran, matlab, octave, R and python routines" in both academic research work and machine learning / data science code in industrial settings. The whole project kicked off with me ranting about how I was sick of cobbling things together in six or seven different languages.
So interop is a very, very high priority. We have pretty good C ABI interop now. You can just call a C function like this:
We still want better C/C++ interop though. I've already looked into using libclang so that if you have the headers you don't even have to declare what the interface to a function is. That was very preliminary work, but I got some stuff working. Making Julia versions of C struct types transparently would be another goal here.
Another major interop issue is support for arrays of inline structs (as compared to arrays pointers to heap-allocated structs). C can of course do this, but in any language where objects are boxed, it becomes very tricky. We're working on it, however, anyone who wants to discuss, hop on [email protected] :-)
I've been waiting for Fortress for a LONG time, but either progress has been real slow or the Fortress team has trouble communicating their progress to the community. Probably both.
From a quick look I can tell that while Fortress is more similar to Scala, with classes, mixins and static typing, Julia is closer to Clojure, with no encapsulation, dynamic typing, homoiconicity, and separation of behavior (methods) from concrete types (akin to Clojure's protocols).
I really like the choices Julia's designers have made, particularly multiple-dispatch methods, final concrete types and lispy macros. The language seems very elegant. Not too crazy about "begin" and "end" syntax, though :)
And what should the library writers use? The great advantage of this is that much of it can be done in one language.
From the article: "The library, mostly written in Julia itself, also integrates mature, best-of-breed C and Fortran libraries for linear algebra, random number generation, FFTs, and string processing."
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!
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.
I wasn't able to tell if it is possible to overload operators, which is another thing essential to mathematical code.
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.
I also didn't see bignums as a default type (though you can use an external library to get them).
However, all in all, I think this is the first 21st Century language and find it very exciting!
Thanks for the incredibly high praise. It definitely is possible to overload operators — operators are just functions with special syntax (see http://julialang.org/manual/functions/#Operators+Are+Functio...). We don't have bignum support, but adding it via GMP would be fairly easy. Just too many things to do!
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:
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.
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 believe what they're saying is that there are two things:
1. The Julia core, which consists of the language runtime and core functionality, is MIT licensed, and builds into an MIT-licensed shared library.
2. The Julia "environment", which includes a user interface, third-party libraries, etc., some of which are GPL, and which is therefore GPL as a whole.
I believe they're saying that you can link #1 with proprietary code, not meaning to imply that you can link #2 with proprietary code (because as you point out that wouldn't work). How useful that is probably depends on how many of the libraries the average application needs are in bucket #1.
The FSF interpretation is undermined by the existence of non-GPL Linux programs (that link, call and use data structures from the (GPL-licensed) Linux API).
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.
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.
PyPy is missing complex support in numpy (on trunk anyway) and numpy.random to run those benchmarks. Those that run:
fib - roughly the same time as CPython
parse_int - 10x over CPython which is extrapolating to their python vs julia about 20% slower
quicksort - 4x faster than cpython much slower than julia.
pi_sum - 20x faster than cpython, a bit faster than julia?
Those are very unscientific measurments. Both fib and qsort are recursive benchmarks (why would you write qsort recursively??), so I guess the JIT does not have time to kick in (and PyPys support kinda sucks for recursion at least in terms of warmup times).
On a slightly unrelated note - a modified lxml library runs on pypy albeit a lot slower right now.
It's not yet another language that we need. It's more high level functions.
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?
If the problem IS that it's huge and inelegant, then the solution isn't to try to improve it, but to start from a clean slate. Julia looks like a reasonable attempt.
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:
import time
def fib(n):
if n < 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 < tmin: tmin = t
print str(tmin*1000)
That's quite true, but this micro-benchmark wasn't chosen to make Python look bad — it was chosen to test how good each language was at function calls. So using a loop defeats the point of the benchmark. Using double recursion to compute Fibonacci numbers is also stupid and could obviously be avoided in all languages.
The story the micro-benchmark tells is that Julia's pretty good at function calls, but JavaScript is even better (and, of course, C/C++ is the gold standard). In general the V8 engine is really amazing. We had the advantage of being able to design the language to make the execution fast (with the constraints of all that we wanted to be able to do with it), but V8 makes a language that was in no way designed for performance and makes it blazingly fast.
After I wrote the benchmark code for JavaScript and saw just how fast it was I had a moment of "should we be doing scientific computing in JavaScript?" Now wouldn't that be nuts?
this is surprisingly complete for a relatively new(?) project.
one notable restriction is that inheritance is only for interface, not implementation.
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?!
[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...]
pron is right: you can inherit behavior from abstract types and abstract types, unlike interfaces, can have code written to them. (In single-dispatch OO languages, you are in the strange situation that you can write code to interfaces if they are arguments but not if they are the receiver of a method; thus, you're in a situation where you can either dispatch on an interface or you can write code for it, but never both at the same time.)
Arrays are not fixed size: there are push, pop, shift and unshift operations on them just like Perl, Ruby, etc. This uses the usual allocation-doubling approach so that the entire array doesn't need to be copied every time, but it's still usually much better to pre-allocate the correct size. Of course for small arrays that are typical in Perl, Ruby, etc., it hardly matters. If you're building an vector of 1 billion floats, however, you don't want to grow it incrementally.
The sequence/iterable abstraction is duck-typed: an object has to implement methods for three generic functions:
i = start(x)
done(x,i)
next(x,i)
The state i can be anything.
Lack of implementation inheritance is one of those things that intro to OO books make a big deal of, but when you don't have it, you don't miss it at all — or at least I don't. I've never found tacking a few fields onto the end of an object to be very useful. I don't want to inherit memory layout — I want to inherit behavior. Julia's type system lets you write behavior to abstract types and inherit that for various potentially completely different underlying implementations.
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:
brew install wget
[Edit] git page says gfortran (and wget) are downloaded and compiled, but if they're not already installed make fails. So...
brew install gfortran
The need to do this separately may have to do with licensing?
[Edit] And if you're not root, install to /usr/share/julia will fail. So you'll need to do:
sudo make install
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.
I once designed/implemented a language where the biggest mistake I made was using 1-based indexing. At first it looked like it was going to be easier to understand/use but 0-based indexing is actually much more convenient when dealing with indexes arithmetic.
Pretty tied into Python/Numpy ecosystem & 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.
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.
We used to use curl until recently so that it would build just fine on OS X. We changed it to wget, because it just seems so much easier to use than curl, and we had to do some nasty stuff at one point to download a few libraries that I couldn't figure out how to do with curl.
BTW, do try out the mac binaries if the build is an issue. We are still trying to make it all build seamlessly!
[+] [-] mjw|14 years ago|reply
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.
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.
[+] [-] StefanKarpinski|14 years ago|reply
So interop is a very, very high priority. We have pretty good C ABI interop now. You can just call a C function like this:
and it works. It works in the repl too and you can dynamically load new libraries in the repl. See this manual page for more details: http://julialang.org/manual/calling-c-and-fortran-code/.We still want better C/C++ interop though. I've already looked into using libclang so that if you have the headers you don't even have to declare what the interface to a function is. That was very preliminary work, but I got some stuff working. Making Julia versions of C struct types transparently would be another goal here.
Another major interop issue is support for arrays of inline structs (as compared to arrays pointers to heap-allocated structs). C can of course do this, but in any language where objects are boxed, it becomes very tricky. We're working on it, however, anyone who wants to discuss, hop on [email protected] :-)
[+] [-] pron|14 years ago|reply
From a quick look I can tell that while Fortress is more similar to Scala, with classes, mixins and static typing, Julia is closer to Clojure, with no encapsulation, dynamic typing, homoiconicity, and separation of behavior (methods) from concrete types (akin to Clojure's protocols).
I really like the choices Julia's designers have made, particularly multiple-dispatch methods, final concrete types and lispy macros. The language seems very elegant. Not too crazy about "begin" and "end" syntax, though :)
[+] [-] wbhart|14 years ago|reply
From the article: "The library, mostly written in Julia itself, also integrates mature, best-of-breed C and Fortran libraries for linear algebra, random number generation, FFTs, and string processing."
[+] [-] fijal|14 years ago|reply
[+] [-] wbhart|14 years ago|reply
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.
I wasn't able to tell if it is possible to overload operators, which is another thing essential to mathematical code.
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.
I also didn't see bignums as a default type (though you can use an external library to get them).
However, all in all, I think this is the first 21st Century language and find it very exciting!
[+] [-] StefanKarpinski|14 years ago|reply
[+] [-] cheald|14 years ago|reply
Lua also has 1-based arrays. Heh.
[+] [-] ludwigvan|14 years ago|reply
[+] [-] jfager|14 years ago|reply
[+] [-] mkl|14 years ago|reply
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.
The FSF disagrees (http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins):
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.
[+] [-] _delirium|14 years ago|reply
1. The Julia core, which consists of the language runtime and core functionality, is MIT licensed, and builds into an MIT-licensed shared library.
2. The Julia "environment", which includes a user interface, third-party libraries, etc., some of which are GPL, and which is therefore GPL as a whole.
I believe they're saying that you can link #1 with proprietary code, not meaning to imply that you can link #2 with proprietary code (because as you point out that wouldn't work). How useful that is probably depends on how many of the libraries the average application needs are in bucket #1.
[+] [-] tomp|14 years ago|reply
[+] [-] drats|14 years ago|reply
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.
[+] [-] fijal|14 years ago|reply
On a slightly unrelated note - a modified lxml library runs on pypy albeit a lot slower right now.
Cheers, fijal
EDIT: updated formatting
[+] [-] DasIch|14 years ago|reply
[+] [-] almost|14 years ago|reply
[+] [-] spitfire|14 years ago|reply
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.
[+] [-] blacksqr|14 years ago|reply
[+] [-] SomeCallMeTim|14 years ago|reply
I came across this bit of humor a while back that communicates the general feeling well:
http://bit.csc.lsu.edu/~gb/csc4101/Reading/gigo-1997-04.html
If the problem IS that it's huge and inelegant, then the solution isn't to try to improve it, but to start from a clean slate. Julia looks like a reasonable attempt.
[+] [-] disgruntledphd2|14 years ago|reply
[+] [-] vilya|14 years ago|reply
[+] [-] kghose|14 years ago|reply
[+] [-] StefanKarpinski|14 years ago|reply
The story the micro-benchmark tells is that Julia's pretty good at function calls, but JavaScript is even better (and, of course, C/C++ is the gold standard). In general the V8 engine is really amazing. We had the advantage of being able to design the language to make the execution fast (with the constraints of all that we wanted to be able to do with it), but V8 makes a language that was in no way designed for performance and makes it blazingly fast.
After I wrote the benchmark code for JavaScript and saw just how fast it was I had a moment of "should we be doing scientific computing in JavaScript?" Now wouldn't that be nuts?
[+] [-] andrewcooke|14 years ago|reply
one notable restriction is that inheritance is only for interface, not implementation.
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?!
[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...]
[+] [-] StefanKarpinski|14 years ago|reply
Arrays are not fixed size: there are push, pop, shift and unshift operations on them just like Perl, Ruby, etc. This uses the usual allocation-doubling approach so that the entire array doesn't need to be copied every time, but it's still usually much better to pre-allocate the correct size. Of course for small arrays that are typical in Perl, Ruby, etc., it hardly matters. If you're building an vector of 1 billion floats, however, you don't want to grow it incrementally.
The sequence/iterable abstraction is duck-typed: an object has to implement methods for three generic functions:
The state i can be anything.Lack of implementation inheritance is one of those things that intro to OO books make a big deal of, but when you don't have it, you don't miss it at all — or at least I don't. I've never found tacking a few fields onto the end of an object to be very useful. I don't want to inherit memory layout — I want to inherit behavior. Julia's type system lets you write behavior to abstract types and inherit that for various potentially completely different underlying implementations.
[+] [-] pron|14 years ago|reply
Not quite. You do inherit methods defined on abstract types.
[+] [-] karpathy|14 years ago|reply
[+] [-] warmfuzzykitten|14 years ago|reply
brew install wget
[Edit] git page says gfortran (and wget) are downloaded and compiled, but if they're not already installed make fails. So...
brew install gfortran
The need to do this separately may have to do with licensing?
[Edit] And if you're not root, install to /usr/share/julia will fail. So you'll need to do:
sudo make install
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.
[+] [-] fuzzythinker|14 years ago|reply
[+] [-] jhrobert|14 years ago|reply
I once designed/implemented a language where the biggest mistake I made was using 1-based indexing. At first it looked like it was going to be easier to understand/use but 0-based indexing is actually much more convenient when dealing with indexes arithmetic.
PS: the "metaprogramming" stuff is fabulous.
[+] [-] plessthanpt05|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] anamax|14 years ago|reply
The webcast is delayed and there's always something interesting that happens after the camera goes off.
[+] [-] mjcohenw|14 years ago|reply
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.
[+] [-] ViralBShah|14 years ago|reply
BTW, do try out the mac binaries if the build is an issue. We are still trying to make it all build seamlessly!
[+] [-] jfager|14 years ago|reply
http://loopkid.net/articles/2011/09/20/ssl-certificate-error...
Basically, you need to get the right certs and then tell wget to use them.