What's your take on Julia?

For those unfamiliar with it:


I've watched it for a bit, and overall I'm liking it. It mixes and matches the best and worst of a number of other languages.

I'm not sure I'm wild about the lack of an implicit block opener ('begin' or '{') but the use of 'end' is good. I prefer words over symbols -- but again I'm a wirth guy. Even so the syntax feels solid as it removes a lot of 'pointless stuff' so common to the C syntax legacy that so often hobbles other languages.

The triple quoted strings that automatically 'de-indent' in the output might be nice for writing server-side HTML that's nice and formatted, but outputs with a decent amount of whitespace stripped. Switching between minified and not minified becoming as simple as switching between single and triple.

Optional typecasting is something that's only just starting to emerge into ECMAScript, that really gives you the best of both worlds. When for security and performance reasons you want strict typecasting it's available, but when the data you're working on could be any type it can do that as well. That gets a thumbs-up from me as I PREFER strict for most things, but recognize there are places it is just easier to have loose/dynamic variables.

About my only real complaint so far is that it allows for 'on the fly' variable creation and is a bit of a wonk on how scope works... but I'm a big fan of forward declaration since it tends to just reduce code errors and provide a degree of clarity. Block-level scoping is most always just a train wreck in terms of memory thrashing and code comprehension.

Performance-wise it's no slouch either, but it's implemented with LLVM so that's kind of a given.

Anyone else here given it a try and/or started learning this one yet?

Start a personal dev blog on your domain for free and grow your readership.

3.4K+ developers have started their personal blogs on Hashnode in the last one month.

Write in Markdown 路 Publish articles on custom domain 路 Gain readership on day zero 路 Automatic GitHub backup and more

Mark's photo

I've only watched it a little.

When I did numerical/scientific programming, I used Fortran, Matlab, R and numpy. I think Julia could be a step up over those, for different reasons. I wouldn't use it outside of numerical/scientific computing though, which is why I haven't tried it much yet.

One 'rare' feature in big languages that I found interesting was that it has multiple dispatch. Conflicts a bit with its performance goals, perhaps, but nice to explore.

(It seems 'rare' to me, I guess lisp and perl were/are pretty big but I've never tried either).

Show +2 replies
Jason Knight's photo

M Which to me reeks of double-talk and philisophical hoodoo-voodoo -- seriously, the LANGUAGE of that sets off warning bells in my head.

Since I don't see what makes it "dynamic" or how the WORD is even relevant to it, or again where in a compiled or pre-parsed language it would introduce a performance cost. In particular the use of the word "dispatch" makes it sound more like some sort of multithreaded thing, WHICH IT CLEARLY IS NOT.

It just reeks of the type of conceptual, professional educator / professional lecturer marketspeak nonsense that has NOTHING to do with how any of it actually works.

Maybe it's that I learned assembly first then pascal decades ago (in that order), but it's a CALL, not a "dispatch". The ADDRESS of the call determined at compile/parse time based on type UNLESS you're working with loose typecasting -- in which case the WORST you should have is a simple series of compare by type. NOT the end of the world.

Though again, this is someplace where strict typecast languages don't even HAVE this discussion. Which oddly is why my BS alarm is going off so hard over it, is so many of the sites trying to explain "dynamic dispatch" and "multiple dispatch" not only sound like someone's talking out their backside, but they also seem to mention languages like C++ where there is no reason for ANY of this terminology to even be relevant or applicable!

Again, in a compiled language with strict typecasting it's just a call... with loose typecasting it's a simple set of cmp/je back-to-back-to-back by the loose variable's object's "type" parameter. (which if they have ANY sense will be a integer, not the huffing name). Or even more efficient, have the parser build a table of pointers and use the type as an offset. SHL and BX are your friend. Just fill the table where there is no corresponding compatible type with pointers to a RETF... or better still the runtime error handler.

But to be fair, I tend to look at this stuff in a radically different fashion from what's hot and trendy with all the sick buzzwords right now.

Mark's photo

I'm not sure if they're popular terms, but both "dynamic dispatch" and "multiple dispatch" are at least standardized enough to have Wikipedia articles of 1000+ words each. It's not hot and trendy (Lisp was mentioned).

You have done low-level stuff so perhaps you're familiar with vtables, which is just the typical implementation of (single) dynamic dispatch. Given your assembly knowledge, you can probably imagine how to extend it to multiple types. So maybe for you it doesn't need a fancy name, but the rest of us don't know assembly, so we rather use "multiple dispatch" than talk about pointers and jump tables.

The term is relevant to C++. Virtual methods are dispatched (or "called" if you prefer) dynamically: if you call animal.move() then you will call a different move for dogs than for cats. Which one gets called is (sometimes) determined at runtime.

Let's name them "calls with multiple jumps based on object type" if that helps. Julia, apparently, has calls with multiple jumps based on object type.

Jan Vladimir Mostert's photo

I just compile Kotlin code with LLVM, gives me native-like performance too. Optional typing is just weird, prefer type inference.

Julia does look interesting though, might be a good replacement for a lot of stuff that i use Python for, especially the scientific packages.

Mark's photo

I think a naive coder might get better numerical performance and programmer efficiency from Julia, since it already has all the matrix stuff and uses blas/lapack bindings (which are very highly optimized). Which is not to say that with just a bit of extra work you can't get the same with Kotlin. Just that I wouldn't recommend it as a first choice for numerical people.

Jan Vladimir Mostert's photo

How compatible is it with other JVM languages? Can i mix Julia and Java for example in the same project (my assumption is that the Java code will be compiled with LLVM as well in this case)?