[idunning]

Comprehensive! Covers the Lisp-y influences of Julia in great depth.

My perspective on Julia is that it has 3 ingredients:

1. A principled design that derives from the experiences of past programming language and particularly the creator's experiences with Lisps. This is where a lot of the "magic" comes from: multiple dispatch, the type system, metaprogramming, etc. The article covers this aspect.

2. A need to be accessible to those transitioning from other languages, like MATLAB and Python. MATLAB, for example, has guided function naming (although Numpy also has similar names for similar reasons). The author mentions the lack of distinction between creating a variable and changing its binding: I'd suggest this is an example of something affected by this design point.

3. A need to be fast. The author brings up the Int vs BigInt distinction. Python, for example, allows Ints to get as big as you want but at a cost. Adding to Ints is not simply an add instruction, you must do a lot more work. Julia, falling on the side of performance, elects to distinguish between arbitrary BigInts and machine Int.

[StefanKarpinski]

Regarding the Int / BigInt distinction, other issues besides performance, which haven't historically been prominent considerations in new language designs, are interoperability and transparency. In the current design, a Vector{Int} always has the same in-memory representation as it would in C or Fortran – you can take a pointer to the first array element and pass it to a library function using the C ABI and it will just work. You also know exactly how your data is represented and can reason about it. You know, for example, that a Vector{Int} definitely does not require any additional heap allocation besides the inline Int values and that arithmetic operations on Ints will just be machine arithmetic ops. I think that the transparency of the C data and performance models has been one of the major reasons for C's long-lived success. One of the design goals of Julia is to have similarly transparent data and performance models.

[phkahler]

IMHO it is total fail to have int be dependent on the machine architecture. C99 fixed this behavior with types for specific sizes so people could finally write portable code. Julia should adopt 64bit integers by default given its intended audience and the reality that even some phones have 64bit processors. int64_t works on 32bit processors too, but with a performance penalty. Having the range of a variable depend on the machine architecture really went out of style a long time ago.

[StefanKarpinski]

We considered that, but even though 64-bit ints work on 32-bit machines, they are dog slow. Insisting that integers are 64-bit everywhere is basically saying that you want slow for loops, slow array indexing – slow everything – on 32-bit systems. Clearly that's unacceptable in a language that is meant to be fast. So Julia has Int32 and Int64 when you want a specific bit size and Int is always the same size as your pointers. This arrangement is considerably simpler to deal with than C's "integers are whatever size I want them to be! [evil cackle]" approach. In particular, default integers and pointers are always the same size – which is not always the case in C (I'm looking at you, Win64) – so there's only one system-dependent size to worry about.

[ViralBShah]

Great points. To add to the second point, much of the surface syntax also is also similar to Matlab/Octave/Scilab, in addition to function names being similar. Of course, this similarity is only superficial and by design.

[dnautics]

That (and not having daft slow loops is) what got me into Julia from octave. I tried it a while back and the biggest issue was the in equivalency of array{n} and array{n,1} now that that's been fixed, it's awesome.

Parallelization in Julia is still a little scary though, I'm waiting a bit before delving into that.