Perhaps we got off on the wrong foot here as I was a bit aggressive, my apologies for that. I see your use case below as you said, and just want to (hopefully politely) explain that your opinions on this startup atency are still likely incorrect.

I have no illusions that I'll convince you - I don't think anyones ever done that on the internet :) But for educational purposes and anyone else interested read on. Also to be clear - "performance" is probably not the number one you'll see people advocating strongly for Julia. It's moreso because if you're in a position where you're writing code that is being run on 50K databases, and not editing CSS styles - what you're doing fundamentally, at some point under the hood, is mathematics. And the flow and design of the code should reflect that. Julia gets us a lot closer.

A few things before I mention your use case specifically:

Running

    $ julia myprog file_$x.db

in a bash script, 50k times would indeed take that 0.85 seconds per run and would be a ridiculous amount of overhead.

But it would would be the equivalent of the bash script in rust (and actually quite similar, as at the end of the day they both target LLVM)

    $ cargo build --release
    $ ./target/myprog file_$x.db

## Solution 1: Precompiling to reduce startup latency

But obviously you wouldn't compile each time - you'd compile once and distribute the binary, or pre-install the compiled libraries beforehand, whatever. In rust you can obivously easily statically build things and distribute. In python you're just calling pre-built libraries in other languages anyways.

In Julia that's not so easy because we have to carry around the GC, compiler, and even a patched LLVM. (See Why is my "Hello World" executable 300MB?!" posts on PackageCompiler.jl....). But Python obviously has the same issue. Your first solution here is to just precompile all of your libraries and code

With a naive approach:

    $ time julia -q noncompiled_prog.jl                                 
    1.57s user 0.14s system 177% cpu 0.961 total

Using a compiled sysimage with our library:

    $ time julia --sysimage=DataFramesSysImg.so compiled_proj.jl
    0.16s user 0.21s system 21% cpu 1.691 total

## Solution 2: Julia already plays nicely with distributed computing Distributed tasks like you're talking about are literally baked into the language, with macros making it trivial to work with clusters, and yes there are people using it with Slurm. For example...

    @parallel for i=1:N
        someCoolFunction(args)
    end

to parallelize across your cluster.