Hacker News Reader

> the startup speed problem can be solved in Julia and they don't need a rockstar advisor to do it. I think the solutions are already pretty well known.

> And that is already being done. First time to plot will be twice as fast as it used to be in the next Julia release. Further improvements can be done

I'm really, really happy to hear that! I hope the Julia runtime becomes more and more streamlined in the (near) future.

See, I was just stating my use case, without pretense that it is representative at all. Yet I received 20 upvotes in a few minutes, and Julia is maybe the only language where "time to first plot" is a thing. So I'm not completely alone in my (admittedly minoritary) concern.

You say that rewriting everything in Julia would solve my problem. I'm sure that this is the case, but this is not at all my point. Some of us do not want a shell replacement, we want a bc replacement, and julia is a nearly perfect one, if it wasn't for the outrageously slow startup time. I have zero interest in the julia REPL, I just write julia scripts (among scripts in other languages) and I'm not willing to change that.

Julia is a compiled language, like C. Using it in this way is basically like writing a shell script in C and calling GCC on every invocation. You can't expect good performance from that, and it's really a testament to Julia that it feels so dynamic that you feel as it it should do that.

If you AOT-compiled your Julia "script" (program) to a binary and invoked that, your startup time problems would go away. Julia's "application deployment" stack is underdeveloped compared to its REPL experience, but it's still possible to do this today with PackageCompiler.jl and will only get easier with time. I think that will prove to be the "right" way to solve this problem in the long run.

(Or, if you don't care about performance, you can just turn off the compiler and interpret everything, and you basically have Python-but-in-Julia. Fast startup, slow running. Just run it with julia --compile=no)

> writing a shell script in C and calling GCC on every invocation. You can't expect good performance from that

Of course you can. Have you ever used the "-run" option of the TCC compiler? It's blazingly fast. With gcc it's a bit slower, but still orders of magnitude faster than julia. You can use pre-compiled libraries and the linking to your freshly compiled code is extremely fast. The fact is that compiling and linking C code is much faster that just launching the Julia environment with some packages. There's no fundamental reason for that enormous disparity in running time. I agree that it is a completely irrelevant nuisance for most people; but still, for some workflows not blessed by the Julia developers, it is the main point of friction.

EDIT: if you want to try it yourself, write the following text into a .c file, chmod +x it, and you can run it like a C script on most unix systems:

    //usr/bin/gcc -O0 "$0" -lpng && exec ./a.out "$@"
    #include <png.h>
    int main(int c, char *v[])
    {
            // do stuff with png images
            return 0;
    }

Point taken, but I think you overreach a bit with:

>There's no fundamental reason for that enormous disparity in running time

I mean... Julia does full type inference, which it uses to present a dynamic type interface. It's not necessarily possible to statically compile a module ahead of time, because the module is designed to be generic and will generate different code if fed different types, which is how Julia attains its extraordinary composability. In other words, it's a much nicer language than C, and correspondingly much harder to compile. I'd call that a pretty fundamental reason.

Perhaps C was a poor example for me to pick. C++, maybe?

p.s. your "script" example clobbers any file named "a.out" in the current directory.

> In other words, it's a much nicer language than C, and correspondingly much harder to compile.

Sounds like an anti-feature to me. What I want is "matlab with fast loops". I couldn't care less about "extraordinary composability", "full type inference" or "genericity". Well, I do care because these unneeded features make my stuff much slower. It's a hefty price to pay for uncalled-for features!

Yes, my script was just a silly joke, to show that compiling and linking C code is really fast.

Do you want a dynamic language with the speed of C? Then you want type inference.

This is not necessary. There could be a single type, for example (e.g., the multidimensional array of floats).

And how do you multiple dispatch on that?

But if you just want a free MATLAB, use Octave.

yep, Octave is what I currently use when I can choose. I loved the concept of Julia as an "octave with fast loops". But it seems that there are some compromises with the Julia interpreter that go against my intersts. Maybe thee's still space for a modern language for numerical computation whose efficiency is not encumbered by the need to support strings, dictionaries, multiple dispatch and the like?

> Maybe thee's still space for a modern language for numerical computation whose efficiency is not encumbered by the need to support strings, dictionaries, multiple dispatch and the like?

I don't think so: I don't know of any scientific code that doesn't have to interact with its environment, if only to import/export data, and for that, strings at the very least are necessary.

Multiple dispatch is the same thing for me; either it or another form of polymorphism will be very quickly asked for by the users of a scientific language, as no one wants to write dozens of time the same functions for different types, and the HPC community loves its programs to go fast, so they need/want to be able to chose their types.

Okay, so go code in Fortran and be happy. Why are you complaining?

This seems too obvious to even comment, but timing the compilation of a no-op program doesn’t show much. The meaningful comparison would be compiling a C program that does the same thing as some Julia code with `gcc -O2`. Btw, you can also run Julia in `-O0` or even better `-O1` mode — Julia even uses these same flags at the command line. These low optimization modes are extremely snappy — time to first plot is no issue. Of course, if you want to run some compute intensive code, it’s much slower, which is why `-O1` isn’t the default.

This is not to dismiss the TTFP issue, just pointing out that your argument seems to be that gcc is faster than Julia, which is definitely not the case. Indeed, gcc is about the same speed as clang, which like Julia, uses LLVM. The way Julia uses LLVM is a bit different, but something would be very wrong if took Julia much longer to compile code with the same functionality as it takes gcc or clang. Julia spreads the compilation out over time, but when you do something complex, a lot of compilation happens all at once. However, a static compilation would not do this work any faster, static compilers just do the work in a separate phase rather than interleaved with execution.

Often the reason I have a bash script is because I'm running some AI tool to solve lots of problems in parallel, gather/filter results, and then gathering results, then finally doing plotting and things.

Personally, I never really like solutions which are "you can't do 5% of stuff in X, you have to do everything in X". I like trying new things out, but I'm not willing to 100% invest everything in Julia up front, rather than just trying out some small bits.

Also, I think my collaborators would get annoyed if I rewrote all our bash scripts in Julia -- I can't expect them all to learn Julia.

A tool with slow startup time that forces me to structure the workflow around its idiosyncrasies is less convenient than a tool with fast startup time that can be seamlessly integrated into pre-existing workflows (eg driving pipelines via Makefiles).