# Can Julia really be used as a scripting language? (Performance)

**URL:** <https://discourse.julialang.org/t/can-julia-really-be-used-as-a-scripting-language-performance/40384>\
**Category:** Performance\
**Created:** [May 29, 2020, 1:06am UTC](https://discourse.julialang.org/t/can-julia-really-be-used-as-a-scripting-language-performance/40384 "2020-05-29T01:06:51Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![singpolyma](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/singpolyma/32/14898_2.png) [@singpolyma](https://discourse.julialang.org/u/singpolyma)\
**Post date:** [May 30, 2020, 12:50pm UTC](https://discourse.julialang.org/t/can-julia-really-be-used-as-a-scripting-language-performance/40384/21 "2020-05-30T12:50:36Z")

</div>

How hard would it be to just compile every package I have installed  
locally into an image like that? shouldn’t that ideally happen every time  
I install a package?

> ## Maybe somebody could distribute a “batteries included” Julia binary that uses PackageCompiler[[GitHub - JuliaLang/PackageCompiler.jl: Compile your Julia Package](https://github.com/JuliaLang/PackageCompiler.jl)] to allow a number of the most popular packages to start up instantly. (This would be aimed at people who simply want to run scripts that they get sent to them, and who are not bothered by not having the very latest versions of packages.)
> 
> Visit  
> Topic[[Can Julia really be used as a scripting language? (Performance) - #20 by Per](https://discourse.julialang.org/t/can-julia-really-be-used-as-a-scripting-language-performance/40384/20)]  
> or reply to this email to respond. To unsubscribe from these emails,  
> click  
> here[[Julia Programming Language](https://discourse.julialang.org/email/unsubscribe/49ff4fcfcb7f97baff489aef00eed15aca02e2ddbeb8258b02686af57181e0bf)].

---

<div class="post-metadata">

**Author:** ![Per](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/per/32/10387_2.png) [@Per](https://discourse.julialang.org/u/Per)\
**Post date:** [May 30, 2020, 2:57pm UTC](https://discourse.julialang.org/t/can-julia-really-be-used-as-a-scripting-language-performance/40384/22 "2020-05-30T14:57:32Z")

</div>

The problem is that each Julia function can be called with an infinite number of different types. It is not possible to compile every combination ahead of time. You’d have to make a list of likely call signatures and compile for that.

---

<div class="post-metadata">

**Author:** ![Tero\_Frondelius](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tero_frondelius/32/7629_2.png) [@Tero\_Frondelius](https://discourse.julialang.org/u/Tero_Frondelius)\
**Post date:** [May 30, 2020, 3:04pm UTC](https://discourse.julialang.org/t/can-julia-really-be-used-as-a-scripting-language-performance/40384/23 "2020-05-30T15:04:19Z")

</div>

> [@Per](#):
>
> each Julia function can be called with an infinite number of different types.

But every script you know all those types ahead of time (or at least have a very good guess of the types). Maybe a functionality to compile the script somehow.

---

<div class="post-metadata">

**Author:** ![Per](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/per/32/10387_2.png) [@Per](https://discourse.julialang.org/u/Per)\
**Post date:** [May 30, 2020, 3:07pm UTC](https://discourse.julialang.org/t/can-julia-really-be-used-as-a-scripting-language-performance/40384/24 "2020-05-30T15:07:14Z")

</div>

Sure. PackageCompiler lets you compile into a stand-alone executable if you want.

---

<div class="post-metadata">

**Author:** ![mwolff](https://avatars.discourse-cdn.com/v4/letter/m/c2a13f/32.png) [@mwolff](https://discourse.julialang.org/u/mwolff)\
**Post date:** [May 30, 2020, 5:28pm UTC](https://discourse.julialang.org/t/can-julia-really-be-used-as-a-scripting-language-performance/40384/25 "2020-05-30T17:28:56Z")

</div>

Even the exe file is not as fast as a file compiled from c/c++. There is also startup time delays with the compiled binary. I wouldn’t use Julia for shell scripts, Julia would look like a turtle next to bash, even with --compile=min. The rapid benchmarks are only established within the REPL after second call without compile-time

---

<div class="post-metadata">

**Author:** ![kevbonham](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kevbonham/32/216165_2.png) [@kevbonham](https://discourse.julialang.org/u/kevbonham)\
**Post date:** [May 30, 2020, 8:11pm UTC](https://discourse.julialang.org/t/can-julia-really-be-used-as-a-scripting-language-performance/40384/26 "2020-05-30T20:11:49Z")

</div>

> [@singpolyma](#):
>
> I totally understand that for the “data science” use case Julia is advertised for, this is reasonable. If I want to ship a script to users, though, it needs to work as a script

True. I’ve sort of come around to the notion that it might be better to ship a package instead.

I don’t mean to say “you’re doing it wrong.” This is a thing that I really want julia to be good at. I’m a pretty hardcore julia fanboy, this is like the _one thing_ that I think is better in other languages. It’s sad because it’s a pretty big barrier for a lot of bioinformatics people that I would otherwise be evangelizing to (well, I still evangelize, but I don’t really have a good answer to this criticism, and it’s a big one).

> [@Per](#):
>
> Sure. PackageCompiler lets you compile into a stand-alone executable if you want.

My understanding is that the primary obstacle to this is the size of the binary, no? I haven’t actually tried it myself.

---

<div class="post-metadata">

**Author:** ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)\
**Post date:** [May 30, 2020, 8:39pm UTC](https://discourse.julialang.org/t/can-julia-really-be-used-as-a-scripting-language-performance/40384/27 "2020-05-30T20:39:15Z")

</div>

One should definitely ship a package. If nothing else, then it will be able to set up the project exactly as the sender intended. No surprises at the receiver’s end. Scripts are so fragile!

---

<div class="post-metadata">

**Author:** ![singpolyma](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/singpolyma/32/14898_2.png) [@singpolyma](https://discourse.julialang.org/u/singpolyma)\
**Post date:** [May 30, 2020, 8:49pm UTC](https://discourse.julialang.org/t/can-julia-really-be-used-as-a-scripting-language-performance/40384/28 "2020-05-30T20:49:30Z")

</div>

If I ship a package there still needs to be a script that requires/runs  
it

---

<div class="post-metadata">

**Author:** ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)\
**Post date:** [May 30, 2020, 9:06pm UTC](https://discourse.julialang.org/t/can-julia-really-be-used-as-a-scripting-language-performance/40384/29 "2020-05-30T21:06:04Z")

</div>

I would say it is rather like this: the package _provides_ the script.

---

<div class="post-metadata">

**Author:** ![kevbonham](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kevbonham/32/216165_2.png) [@kevbonham](https://discourse.julialang.org/u/kevbonham)\
**Post date:** [May 30, 2020, 11:13pm UTC](https://discourse.julialang.org/t/can-julia-really-be-used-as-a-scripting-language-performance/40384/30 "2020-05-30T23:13:51Z")

</div>

> [@singpolyma](#):
>
> If I ship a package there still needs to be a script that requires/runs  
> it

If your script takes no user input, yes. But if your script has any sort of interface, I think not really. Again, I’m only speaking from my experience, but I’m thinking a lot of stuff I’d write would be something like

```sh
$ my_script proccess some_file1.txt --output thing1.xyz
$ my_script plot thing1.xyz --figure-type bar

```

Not much harder to do

```julia
using MyPackage

process("some_file1.txt", output="thing1.xyz")
bar("thing1.xyz")

```

---

<div class="post-metadata">

**Author:** ![Per](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/per/32/10387_2.png) [@Per](https://discourse.julialang.org/u/Per)\
**Post date:** [May 31, 2020, 7:38am UTC](https://discourse.julialang.org/t/can-julia-really-be-used-as-a-scripting-language-performance/40384/31 "2020-05-31T07:38:09Z")

</div>

> [@kevbonham](#):
>
> My understanding is that the primary obstacle to this is the size of the binary, no?

Haven’t actually tried it either, but as I understand it, yes, the binary will always include the entire Julia runtime. (It might still be a convenient way to let everyone that you share a file system with run your code.)

This is why I suggested that “somebody” should distribute a binary with a bunch of packages built-in. (An extended standard library, of sorts.) That would make it possible to distribute fast-running small scripts or packages with only infrequent updates of a large binary.

---

<div class="post-metadata">

**Author:** ![kevbonham](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kevbonham/32/216165_2.png) [@kevbonham](https://discourse.julialang.org/u/kevbonham)\
**Post date:** [May 31, 2020, 12:59pm UTC](https://discourse.julialang.org/t/can-julia-really-be-used-as-a-scripting-language-performance/40384/32 "2020-05-31T12:59:56Z")

</div>

> [@Per](#):
>
> This is why I suggested that “somebody” should distribute a binary with a bunch of packages built-in.

It’s not a bad idea, though I predict endless bike shedding about which packages are in the expanded set

---

<div class="post-metadata">

**Author:** ![Per](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/per/32/10387_2.png) [@Per](https://discourse.julialang.org/u/Per)\
**Post date:** [May 31, 2020, 1:42pm UTC](https://discourse.julialang.org/t/can-julia-really-be-used-as-a-scripting-language-performance/40384/33 "2020-05-31T13:42:35Z")

</div>

Whoever builds the binary (and pays for the bandwidth) would get to decide. But if a package that I need is not included, it won’t prevent my script/package from working. (It will just be slightly slower.)

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [May 31, 2020, 4:47pm UTC](https://discourse.julialang.org/t/can-julia-really-be-used-as-a-scripting-language-performance/40384/34 "2020-05-31T16:47:20Z")

</div>

I think it would be best to make the complete build & CI framework for such a binary available in a repo, also automating the compilation of this “binary” (as a released asset). Then those who need extra packages in it could just fork and modify.

---

<div class="post-metadata">

**Author:** ![tbeason](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tbeason/32/15898_2.png) [@tbeason](https://discourse.julialang.org/u/tbeason)\
**Post date:** [May 31, 2020, 5:47pm UTC](https://discourse.julialang.org/t/can-julia-really-be-used-as-a-scripting-language-performance/40384/35 "2020-05-31T17:47:44Z")

</div>

This sounds like a good thing to try.

---

<div class="post-metadata">

**Author:** ![dlakelan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dlakelan/32/8491_2.png) [@dlakelan](https://discourse.julialang.org/u/dlakelan)\
**Post date:** [May 31, 2020, 6:24pm UTC](https://discourse.julialang.org/t/can-julia-really-be-used-as-a-scripting-language-performance/40384/36 "2020-05-31T18:24:35Z")

</div>

Is this substantially different in speed from just having a script that first adds packages and then precompiles them which you execute once every so often when you want to update your packages?

I’m asking because I kind of want a batteries included data analysis, visualization, and modeling package set, but it seems really easy to just have a script that does Pkg.add(…); Pkg.precompile() that I run every so often, and I’m not in the situation where I’m shipping a “script” so running this “install script” every so often is fine for me. But if it’s going to be a lot faster when I want to use it to have a built binary, then I’d like to know.

---

<div class="post-metadata">

**Author:** ![ppalmes](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ppalmes/32/6838_2.png) [@ppalmes](https://discourse.julialang.org/u/ppalmes)\
**Post date:** [May 31, 2020, 10:07pm UTC](https://discourse.julialang.org/t/can-julia-really-be-used-as-a-scripting-language-performance/40384/37 "2020-05-31T22:07:37Z")

</div>

julia can follow similar idea of debian popularity contest package. julia repl can from time to time submit frequently used packages to a central server which can then collate the most popular packages to be included in the sysimage in a fair way. or possibly create a website that accepts list of packages and will automatically create a sysimage that can be downloaded.

---

<div class="post-metadata">

**Author:** ![Henrique\_Becker](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/henrique_becker/32/15443_2.png) [@Henrique\_Becker](https://discourse.julialang.org/u/Henrique_Becker)\
**Post date:** [May 31, 2020, 10:36pm UTC](https://discourse.julialang.org/t/can-julia-really-be-used-as-a-scripting-language-performance/40384/38 "2020-05-31T22:36:33Z")

</div>

Why would scripts be fragile? A script with a Project.toml/Manifest.toml and a call to `Pkg.activate` and `Pkg.instantiate` inside it, is as solid as a package, in terms of reproducibility, no? The only “problem” is calling it with the “wrong” Julia version, but there are probably workarounds for it.

---

<div class="post-metadata">

**Author:** ![Henrique\_Becker](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/henrique_becker/32/15443_2.png) [@Henrique\_Becker](https://discourse.julialang.org/u/Henrique_Becker)\
**Post date:** [May 31, 2020, 10:45pm UTC](https://discourse.julialang.org/t/can-julia-really-be-used-as-a-scripting-language-performance/40384/39 "2020-05-31T22:45:29Z")

</div>

> [@Per](#):
>
> The problem is that each Julia function can be called with an infinite number of different types.

Not if you either: (1) restrict all the function arguments to concrete types, so there is only one tuple of types the function can be called with; (2) wrap every argument with [`@nospecialize`](https://docs.julialang.org/en/v1/base/base/#Base.@nospecialize) that is what I do for functions I know that will only be run by the script (are defined inside it) and for convenience I want them to be able to take many different types (that will be passed to `Base` functions that already deal with those different types so I do not need to write `if isa(...)` in my code).

Obviously this applies to the methods you define for your scripts. You can only avoid calling functions defined elsewhere with too many different argument types without necessity (like `String` vs `Symbol`, or different number types).

---

<div class="post-metadata">

**Author:** ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)\
**Post date:** [May 31, 2020, 11:47pm UTC](https://discourse.julialang.org/t/can-julia-really-be-used-as-a-scripting-language-performance/40384/40 "2020-05-31T23:47:00Z")

</div>

I was advocating for the same thing that you described here. A script alone (meaning without a defined environment) is fragile. But if the script comes with an environment it becomes much more robust. In other words, your comment is agreeing with me. 🙂

[Previous page](https://discourse.julialang.org/t/can-julia-really-be-used-as-a-scripting-language-performance/40384.md?page=1)

[Next page](https://discourse.julialang.org/t/can-julia-really-be-used-as-a-scripting-language-performance/40384.md?page=3)