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:

  ccall(:getpid, Uint32, ())

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] :-)

Naive question (and I'll hold my tongue on my naive guesses): I understand why it is necessary to box user-defined types on the JVM, but why build this restriction into a new language that doesn't run on a restricted platform? Especially when performance and C interop are high priorities?

Or perhaps I misunderstood, and your statement should be read as sparsevector suggested.

It seems that in dynamically typed languages, you either need to have two kinds of objects (value types vs. object types), or two kinds of storage slots (e.g. arrays that hold values inline vs. arrays that hold references to heap-allocated values). The boxing aspect is really only part of that since you can't get the shared-reference behavior unless the storage is heap-allocated, regardless of whether there's a box header or not.

So yeah, it's a complicated issue.

One other slight difficulty seems to be the lack of finilisers, e.g. to clean up a GMP bignum when there are no remaining references to it.

Oh, so arrays of complex numbers are implemented as arrays of pointers to objects? That would give really bad CPU cache performance.

The longer-term approach is still up in the air and that's what I was talking about above. My favorite approach at this point is to allow fields to be declared as const — which in Julia means write-once. Then if all fields are const the object is immutable and can automatically be stored in arrays inline.

What's the problem to have arrays of doubles and complexes as "basic" types even in the dynamic language? I believe this could give you a C footprint and C performance with array operations?

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 :)

Chapel has made a lot of progress in the past 2.5 years (while we've been working on Julia) and is certainly a contender.

Julia certainly aims to be more dynamic like Clojure, but specially designed to be good for numerical and technical stuff, and yes, the begin/end is due to Matlab — scientists who have a lot of code in Matlab already are a major target demographic. As it is, a lot of Matlab code ports over with relatively trivial changes (see: http://julialang.org/manual/getting-started/#Major+Differenc...), which was the point of syntactic similarity to Matlab.

Octave has solved this by allowing both matlab-style "end", as well as block-specific endings, like "endif", "endfunction", "endfor", etc.

Having several end end end endings without any hint of what they are closing is one of the ugliest parts of matlab. Even though you are reimplementing this for compatibility reasons, it is rather sad that you chose to make this the default behaviour for Julia.

Braces would be better than ending keywords, in my opinion, but I'm disappointed not to see whitespace-defined blocks of a la Python. Perhaps that doesn't work in a statically-typed, type-inferred language, but if it does, I think it would be much better. Scientists have no problem with it (certainly less of a problem than programmers do) and Python is pretty well accepted in the scientific computing community.

If I weren't excited about it, I wouldnt even be commenting on it. ;)

I disagree. Besides (), [], {}, and <>, there's plenty of other paired punctuation available in Unicode, such as...

⦃⦄⦅⦆⦇⦈⦉⦊⦋⦌⦍⦎⦏⦐⦑⦒⦓⦔⦖⦕⦗⦘⧘⧙⧚⧛⧼⧽〈〉《》「」『』【】〔〕〖〗〘〙〚〛❨❩❪❫❬❭❮❯❰❱❲❳❴❵⟦⟧⟨⟩⟪⟫

Nothing is as bad, though, as the default Matlab behavior of not indenting first-level function code. This makes it really hard to scan a file with multiple functions and see where they separate.

When I said "easy fix" I meant "a trivial extension to the parser" without realizing you would translate that to "really low priority". Guess I'll save my non-trivial suggestions. :)

http://bartoszmilewski.wordpress.com/2011/11/07/supercomputi...

http://lambda-the-ultimate.org/node/4405

After that proposal is implemented (perhaps in version 3 of Scala, almost ten years after its first release, though granted it wasn't their top priority) they'll still have to write at least a little bit of boilerplate for each type they want to store in unboxed arrays, and they'll be limited to types that can be stored as Java primitive types under the covers. That seems like a pretty nasty limitation for a general-purpose scientific computing language, not only because it decreases native performance but because it makes C interop much more difficult.

For a general-purpose scientific language, I think it is imperative to adopt the principle that any user-designed type should be able to achieve the same power, performance, and elegance as if it were a built-in type. To the best of my knowledge, that rules out JVM languages.

(Scala was never meant to be a "JVM language," but in terms of its strengths, its weaknesses, its user base, and its future, it is very much a JVM language, and the obstacles to implementing efficient user-defined types is one of the trade-offs they accepted when they went with the JVM.)

http://ppl.stanford.edu/main/publications.html

example, this scala DSL:

http://liszt.stanford.edu/liszt_sc2011.pdf

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."

However, much of the code is written in a vectorized style for performance reasons, as is the case with many high level scientific computing languages. This leads to unnatural code in some cases, and also uses too much memory. First I thought IronPython was the way, but have been looking forward to pypy+numpy+scipy eagerly.

If I were to use julia, the code would be a lot more natural, because type inference and all the compiler goodies make it possible to simply write loops over arrays when I need them. This was one of the reasons we started working on julia, because everything else just seemed to fall just a little bit short.

The parallelisation story isn't great at the moment either, although seems like it has the potential to improve. Still 'sucks' is pretty harsh. For me, looking at how far it's come since I first played with it, I'm impressed. For machine learning, the majority of the building blocks one needs are there, and you get to sit back and put them together using a nice, clean, widely-adopted general purpose programming language. And unlike MATLAB still maintain a decent amount of control over things like memory usage and which BLAS routines it's calling.

Adding bindings for new libraries is more of a pain than it should be though on the occasions where you do really need some fortran or C++ library that doesn't have bindings yet. A language which bridges the gap between high and low levels (not C++!) and has great interop would be very interesting. I guess I'm just hopeful that this kind of thing can be achieved in a general-purpose language (new or existing) which like Python is adopted across the wider software engineering community. Perhaps that's my unreasonable demand to add to their list :)

Seriously? I mean, I know you are very excited about your work on PyPy, but why do you have to go around saying baseless stuff like this? There are many, many thousands of people who write lots of Python code every day that rely on Numpy, Scipy, and Matplotlib to get their work done, and who seem to be quite pleased with it. There is a lot of work left to do on all parts of that stack, but that's a far cry from "it sucks".

The general consensus, if you look at languages like Chapel and Fortress and X10, seems to be that most scientific codes shouldn't be written using for-loops. That is the low-level control flow construct dating from the age of assembler. Instead, what scientists generally want to say is, "Apply this kernel across this domain, with these windowing conditions", or "Reduce values from this computation along these keys in my dataset". As software developers, our job is to provide the language runtime to allow them to do that; such a runtime will be the most robust, correct, maintainable, and performant.

The problem with numpy's performance is twofold:

* Numpy expressions might not be fast enough. I believe you guys at continuum are trying to address that one way or another. In general the kernel expressed using high-level constructs in python should not be slower than an equivalent loop in C.

* Sometimes you actually want to write a for loop, because you don't care, because it's faster, because it's a single run, because the data is manageable etc. You should not be punished for doing that with 100x performance drop. You can still be punished for that with 2x performance drop.