ML needs a new programming language – Interview with Chris Lattner

What's the current state of time to first plot and executable size? Last time it was several seconds to get a 200 MB hello world. I'm sure they are moving in the right direction the only questions is are they there yet?

with juliac.jl and --trim, hello world is now 1MB and compiles in a second.

more realistic examples of compiling a Julia package into .so: https://indico.cern.ch/event/1515852/contributions/6599313/a...

improving, slowly. 5 steps forward 3 steps back.

1.9 and 1.10 made huge gains in package precompilation and native code caching. then attentions shifted and there were some regressions in compile times due to unrelated things in 1.11 and the upcoming 1.12. but at the same time, 1.12 will contain an experimental new feature `--trim` as well as some further standardization around entry points to run packages as programs, which is a big step towards generating self-contained small binaries. also nearly all efforts in improving tooling are focused on providing static analysis and helping developers make their program more easily compilable.

it's also important a bit to distinguish between a few similar but related needs. most of what I just described applies to generating binaries for arbitrary programs. but for the example you stated "time to first plot" of existing packages, this is already much improved in 1.10 and users (aka non-package-developers) should see sub-second TTFP, and TTFX for most packages they use that have been updated to use the precompilation goodies in recent versions

julia> @time begin

       using Plots

       display(plot(rand(8)))

       end

  1.074321 seconds

On Julia 1.12 (currently at release candidate stage), <1mb hello world is possible with juliac (although juliac in 1.12 is still marked experimental)

I recently looked into making Julia binaries, and it's not at all a good process. They say it's supported, but it's not exactly as easy as "cargo build" to get a Julia binary out. And the build process involves creating this minimal version of Julia you're expected to ship with your binary, so build times were terrible. I don't know if that gets amortized though.

As far as the executable size, it was only 85kb in my test, a bouncing balls simulation. However, it required 300MB of Julia libraries to be shipped with it. About 2/3 of that is in libjulia-codegen.dll, libLLVM-16jl.dll. So you're shipping this chunky runtime and their LLVM backend. If you're willing to pay for that, you can ship a Julia executable. It's a better story than what Python offers, but it's not great if you want small, self-contained executables.

note that as a few other commenters have pointed out, this situation will improve greatly in 1.12 (although still many rough edges)

Yeah, that's what I've been hearing about Julia for about 10 years now: "situation will improve greatly in the next version, but still many rough edges remain".

I've been involved in a few programming language projects, so I'm sympathetic as to how much work goes into one and how long they can take.

At the same time, it makes me wary of Julia, because it highlights that progress is very slow. I think Julia is trying to be too much at once. It's hard enough to be a dynamic, interactive language, but they also want to claim to be performant and compiled. That's a lot of complexity for a small team to handle and deliver on.

Different things have been improving for the past 10 years. TTFX is in a good spot now, multithreading is in a pretty good spot now, GC issues for most people are basically solved. AOT compilation was pretty much the last big item that a lot of people wanted, and that has recently (within the last year) gotten to the point where the code exists, it's merged, and it will be releasing soon (and then spending the next year or two getting improved)

That has been the situation with many programming languages until they finally explode, including Python, which is 34 years old, and also was largely ignored for a decade until Zope in 2000's.