Elevator pitch

How would one explain the compile/run model of Julia? As indicated in the title of this topic, in one minute or less. Evidently, I do have some ideas, but I’m sure someone can do it better, and so I am looking for ideas. Please don’t be shy.

3 Likes

Who is your audience? If you’re limited to one minute I try to speak their language as much as possible.

1 Like

Domain experts (engineering/scientific computing), not CSE or sw engineers.

^ Yes; and include at least one descriptive analogy where the analogue is a matter their expertise elucidates, then very briefly retrace how that analogy actually is elucidative.

I tend to think of the Julia model as a kind of flexible and agile compile/link/run cycle. Compared to C++ the build (compile plus link) is nearly invisible (except for the occasional delay). Configuration also tends to be much less onerous. (Even though when interfacing with actual C++ libraries there are some headaches in the build process. But again, as long as one just adds a package, these configuration options are nearly painless.)

1 Like

designandedit/compile/runtests/run/improve/release

The phrase I like is “just-barely-ahead-of-time-compiled.” If it’s someone coming from C++, you can do one better and say it’s kinda like all your functions are templates — they get specialized for exactly the arguments you passed it, so they’re super fast, but you don’t have horrifying error messages!

If it’s someone coming from a higher-level language, it turns into something like: the functions you write can get compiled just as efficiently as all those built-in functions you’re used to calling in language X. A lot of time in higher-level languages is spent asking meta-questions about your variables: what type are they and how do you do something with them — for every, single operation, even the simplest ones like +!). By specializing and compiling functions for the given set of arguments, Julia knows exactly what types things are and how they behave — and it can completely avoid asking those sorts of meta-questions and instead spends its time actually doing just the work you wanted.

16 Likes

My elevator pitch:

Julia is as flexible as Python, as numerical as Matlab, as fast as Fortran, and as deep as Lisp. How? It’s a well-designed, modern, general-purpose dynamic language aimed squarely at numerics, with the entire langiuage design focused on making just-in-time compilation work as well as possible. You can write a function on the fly, or even generate one computationally, and the first time it’s run, it gets compiled to machine code. On subsequent runs it’s as fast as compiled C or Fortran. And it has hands-down the most comprehensive and powerful set of numeric types of any language to date, and an impressive set of built-in numeric libraries. It’s totally the future of scientific computing.

Of course there are nuances and small corrections for just about everything in that pitch, but it gets the idea across, I think.

5 Likes

These are good points, I believe.
I do remember some explanations that Julia was not really a JIT language. More of a AOT. Any opinions?

1 Like

Yes, but for the regular science and engineering crowd, they’re more likely to have heard of and somewhat understand just-in-time compilation. I’m used to having to explain the difference between interpreted and compiled languages. But whatever works for you, of course!

This talk is much longer than an elevator pitch, but it’s a good explanation of how Julia is compiled: JuliaCon 2017 | AoT or JIT: How Does Julia Work? | Jameson Nash - YouTube .

1 Like

This is also useful here: https://juliacomputing.com/blog/2016/02/09/static-julia.html

Can you do a demonstration, or does it have to be just talking? Something like

julia> f(x) = 2 * x # NOTE: no type annotations
f (generic function with 1 method)

julia> @code_native f(2)
        .text
; ┌ @ REPL[1]:1 within `f'
; │┌ @ REPL[1]:1 within `*'
        leaq    (%rdi,%rdi), %rax
; │└
        retq
        nopw    %cs:(%rax,%rax)
; └

julia> @code_native f(3.0)
        .text
; ┌ @ REPL[1]:1 within `f'
; │┌ @ promotion.jl:310 within `*' @ REPL[1]:1
        vaddsd  %xmm0, %xmm0, %xmm0
; │└
        retq
        nopw    %cs:(%rax,%rax)
; └

may get the point across if the audience has seen assembly before (not know it, just recognize what it is).

Of course, this assumes a pretty well-equipped elevator :wink:

3 Likes

What’s their favorite language and how do they use it? For a truly short pitch, I guess you could say how julia satisfies the core competency they really enjoy in their favorite language. And how it addresses a major pain points in that language. For example…

For matlab programmers: “It looks and feels like matlab for array programming and linear algebra. But all your loops can be as fast as C, and it allows you to build large programs in a structured way. You can use and install it anywhere for free without running a license server!”

For C++ programmers: “Julia functions are as fast as template functions but have nice syntax like normal overloaded functions. What’s more, they can do dynamic dispatch like virtual functions. In Julia you can interactively explore your data and experiment with new algorithms without worrying about about recompiling and reloading the data.”

For python programmers: “Julia code is as succinct and easy to use as python. There’s a wide range of numerical libraries which are easy to install with the builtin package system. Because Juila is fast, they are usually written in Julia itself so you don’t need to know C to understand and modify the libraries you’re using.”

I’m not sure those are great pitches; depends a lot on the audience and how they perceive their language of choice.

16 Likes

These are excellent points. I will try to work it into the tutorial.

I should have been a little bit more precise: I will give a longish tutorial (over two hours), but I do want to have some really crisp statements about major aspects of the language. One of those is the mode of compile/run. Hence my question.

1 Like

May I quote you in the tutorial?

Depending on the audience, it may make sense to separate what Julia achieves from how it is implemented.

Eg code that is succinct, generic, and fast at the same time (“what”) is the result of the combination of parametric types, multiple dispatch, and AOT compilation to the LLVM backend (“how”).

When the message is short, certain audiences may be interested more in the solution, others in the result. Of course when you expand on these things, you have to explain both, otherwise the results are done by “magic” or the features that implement them are not motivated.

3 Likes

I think it is safe to assume that people generally know how Python and how C works. Then one can just make a word game to show that Julia is the best of both worlds:

Python is an interactive interpreted language, easy to use but slow. C is a compiled language, fast but hard to prototype. Julia is an interactive compiler language a solution which gives the best of both worlds. Imagine that you would like to execute a function with specific arguments. You would run it in the REPL as f(x,y) which would start a compilation procedure to types of x and y. The strength of the Julia is that the language is designed in such a way that the compiler can always (almost) infer the function variable types and thus produce code as simple as C. The design of Julia also solves expression problem which makes easy to compose and write packages.

2 Likes

Sure, feel free! I’m sure those pitches could be much improved but if they’re helpful that’s great.

1 Like

Just in case anyone’s interested a tentative version of the tutorial is posted as a package: https://github.com/PetrKryslUCSD/JuliaTutorial2019

Feedback will be appreciated.

2 Likes