An attempt at an easy-to-use dynamic language which tries to compile things early as much as possible via aggressive type inference (helped by the type system's design and multiple dispatch), so that you don't leave performance on the table where it's possible to have it, while also having the flexibility of dynamism where you need it.

That's my interpretation, I'd be curious what Julia folks who actually know what they're talking about think of it.

Matlab that compiles to LLVM. It's fast, pretty easy to write, and surprisingly expressive.

It's also 1-indexed.

I just think it's neat, but it's never solved a meaningful problem for me. My data gets filtered and well-structured upstream of my analysis, so python+pandas is perfect. Visualization tools aren't better in Julia than JS or Python. Really crunchy simulations tend to be written in C or C++.

Julia is a language that you write more or less like python, but in cases where python would chase a million pointers to figure out what the type of a variable is, get an instance variable, call a method, etc, Julia (if written correctly) does just in time compilation. The first time it has to call a function on a combination of types it hasn't seen before, it compiles the function for those specific types (into LLVM IR, and then native code) and stores the compiled code so that subsequent dispatches of that function with those types are instantaneous, calling directly into the compiled code. You do not need to add type annotations for this to happen; at runtime, Julia checks the types of variables (which may have even been determined when the function was compiled, eliding the runtime check, if it was used in a context where the types were statically known; see below) to determine which version of a function to call.

This is a strength, as the only thing you have to do to get the performance of fully compiled code (modulo things like GC and bounds checking) is make sure your functions are “type stable”, i.e., their type information can be determined statically. (In fact, in Julia you get better performance by writing more, smaller functions because you'll have more regions within which the types are statically inferrable.) But it's also a weakness because the first time you start up a REPL and call a bunch of functions, each of those functions has to be compiled from scratch, which takes a long time (google “Julia time to first plot”).

Julia has other niceties such as very flexible math (promotion between every pair of numeric types) and a lisp-like macro system with homoiconic code, which make writing numerical code and scientific algorithms highly ergonomic.

> But it's also a weakness because the first time you start up a REPL and call a bunch of functions, each of those functions has to be compiled from scratch, which takes a long time (google “Julia time to first plot”).

But also to further clarify on this, the context of the article is that Julia 1.9 makes it so that for code in packages, the package authors can set up a "call a bunch of functions" section in the package itself, and the compiled results of those calls will be stored as native code. So anything from those parts will have much lower "time to first X".

modern day fortran

PART 1: THE MEETING.

Of course, Fortran and Matlab had heard of each other. How could they not have, given so many mutual friends? Many of those friends thought that they should meet up. Some even thought they would hit it off. But the common view was that they would dislike each other. Elderly Fortran, who thought deeply before even considering to act on something, didn't see much to gain in meeting Matlab. And Matlab, long the darling of the just-go-for-it crowd, was by now middle-aged, and saw little benefit in dating at all.

But on day, as the joke goes, they both walked into the same bar. Fortran ambled in slowly carrying a musty book and exuding an air of superiority. Matlab arrived a bit later and, busy chatting on the phone, did not even notice Fortran sitting alone in the shadows. But after a while, Matlab did notice a flickering over in that dark corner of the bar. It was a candle. Intrigued, Matlab strode towards the light in the darkness.

Fortran, as always, was deep in thought. Buried in the book, sure, but more than that. Fortran had been thinking about this thing for several weeks. And not just thinking with a single mind, like others in the bar, but at this point with ten thousand minds. The idea was only now just starting to take shape, with these many minds and these many hours.

Now, Matlab was no fool. Matlab could recognize brilliance when it was sitting right there, with the candle, the book and the furrowed brow. The rest of the bar faded away. The music, gone. The conversations, the laughter, the flirting, the clinking of glasses -- all gone. For Matlab had realized something: Fortran was sexy as hell.

So Matlab sat down. And Fortran, to the astonishment of anyone who had been around for the past half-century, looked up. Wow. In this light, in this place, at this moment Matlab seemed like an angel descended from heaven.

They said very few words. And the words didn't really even matter much. It was the tone of voice that mattered. The pauses. The crinkling around the eyes. After a while, Matlab's hand reached for Fortran's. And that was the start of something new. Something neither expected. Something their friends could not have imagined, let alone hoped for.

NEXT: PART 2, JULIA IS CONCEIVED.