
Julia is a high-level, high-performance dynamic programming language - bsiemon
http://julialang.org/
======
freehunter
Previous discussion: <http://news.ycombinator.com/item?id=3606380>

Their site is down right now, so the 10 day old comments might be able to
satisfy some amount of curiosity.

~~~
dr_rezzy
Ditto, this site returns an error everytime I try and hit it.

~~~
Marwy
Works fine for me.

------
jhrobert
"All indexing in Julia is 1-based"

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.

------
anamax
Julia is the subject of today's <http://www.stanford.edu/class/ee380/>

The webcast is delayed and there's always something interesting that happens
after the camera goes off.

------
Flam
Is V8 really faster than NumPy and R? Interesting..

~~~
nichol4s
No, not really.

Not only do some of the example's seem to be created specially to show the
benefit of the JIT compiler (see pisum fe). Most of the example's do not
really use the features of LaPack/BLAS, the one where it does (a matrix
multiplication in rand_mat_mult) shows that all languages which use these
optimized libraries beat Javascript and handwritten C++ with a magnitude of 2.

Thus, be careful with making such a generalisation from this benchmark. Also,
it is much simpler to simply work with a language with proper support for
multi-dimensional matrix slicing than having to do this all by hand.

~~~
StefanKarpinski
As you note, the last benchmark does precisely what you suggest, comparing
completely vectorized code that just calls BLAS. This is a really
uninteresting benchmark, however, since everyone is close to C++ (although
NumPy, Octave and R still introduce 20%, 69% and 165% overhead, respectively)
— because you're really just comparing C++ against C++.

One of the key concepts behind Julia is that not only the end-user, but also
the numerical library writer, should benefit from using a high-level language.
In Julia, almost all of the library code is in Julia, and it's as fast as the
library code written for R, Matlab or NumPy in C. There are also a lot of
situations where vectorized code is either awkward or inefficient — especially
in terms of creating a lot of unnecessary temporary arrays. Languages where
the high-level language is slow force you to do everything vectorized — in
Julia, you're not forced to do that. If you want to write a C-style scalar
loop, you can and it will be fast (and you don't even need type annotations to
make it fast, as shown by the benchmarks).

V8 is really impressively fast, but JavaScript as a language is not very well
suited to scientific or technical computing.

------
ableal
ViralBShah: your account was shadow-banned in the last discussion 10 days ago.

(No reason I can see to ban one of the authors. Check logged out or from
another account with "showdead" on.)

------
SeanLuke
Is there some reason they neglect to compare against Mathematica? Seems like a
glaring omission to me.

~~~
StefanKarpinski
Running Mathematica scripts automatically from the command-line is major pain.
That and just writing the benchmark code. A contribution would be most
welcomed.

~~~
SeanLuke
Mathematica has _always_ had a command line.

    
    
        MathKernel -script "foo.m" -noprompt
    

As to Mathematica being a pain to write code for: I've found it to be a pretty
nice language, certainly a far cry better designed than MATLAB.

------
bleakgadfly
Again?

