# How close is StaticCompile?

**URL:** <https://discourse.julialang.org/t/how-close-is-staticcompile/36880>\
**Category:** General Usage\
**Tags:** question\
**Created:** [April 1, 2020, 11:03pm UTC](https://discourse.julialang.org/t/how-close-is-staticcompile/36880 "2020-04-01T23:03:27Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![peter.wolf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/peter.wolf/32/6018_2.png) [@peter.wolf](https://discourse.julialang.org/u/peter.wolf)\
**Post date:** [April 1, 2020, 11:03pm UTC](https://discourse.julialang.org/t/how-close-is-staticcompile/36880/1 "2020-04-01T23:03:27Z")

</div>

Hello, I am new to the Julia community, and I want to thank you for making a terrific language, wonderful free tools, and very supportive experts that answer questions quickly on Slack and Stack Overflow. I am a big fan.

It was suggested that I raise this issue here

I am a commercial developer who is looking at Julia as a replacement for Python/Cython/C++. I am making an ML product for an employer that is a Java/Python shop. I have written a proto-type in Julia that run 10x faster than my Python version. It is currently being evaluated by several very large customers.

To sell Julia to engineering, I need to be able to package my code in a way that Java and Python can call it, but other engineers do not need to know about Julia. I can not control the architecture, so I need to produce a library.

I used PackageCompiler and PyJulia to plug it into our Python code. This is fine for a prototype, but I think engineering will balk at the 200mb size. Also our build masters don’t know Julia and will have trouble maintaining the build process.

I know that StaticCompiler is under development, and this is a common request

[https://news.ycombinator.com/item?id=21695331](https://news.ycombinator.com/item?id=21695331)

How far away is it, and where is static compiling in the priority list? How close are we to being able to type ‘make …’ and have Julia code compiled to an optimized library or executable?

Many thanks

Peter

---

<div class="post-metadata">

**Author:** ![Oscar\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oscar_smith/32/25343_2.png) [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)\
**Post date:** [April 2, 2020, 12:11am UTC](https://discourse.julialang.org/t/how-close-is-staticcompile/36880/2 "2020-04-02T00:11:38Z")

</div>

It is unlikely that in the near future small (\<100mb) executables will be makable without an extensive test suite. The reason for this is that if you don’t want to include Julia itself in the library, you need to know that you have compiled every method on every possible combination of types which will appear in the program. To know which functions and types to have in the library will require a test suite that exercises every possible use case. Generating everything isn’t an option since a single 5 argument function would then generate over a million different versions if you have 9 different types defined.

---

<div class="post-metadata">

**Author:** ![Ratingulate](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ratingulate/32/9242_2.png) [@Ratingulate](https://discourse.julialang.org/u/Ratingulate)\
**Post date:** [April 2, 2020, 1:08am UTC](https://discourse.julialang.org/t/how-close-is-staticcompile/36880/3 "2020-04-02T01:08:03Z")

</div>

If you follow the link above, Keno seems to think it’s possible, perhaps with some restricted semantics.

---

<div class="post-metadata">

**Author:** ![ssfrr](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ssfrr/32/3736_2.png) [@ssfrr](https://discourse.julialang.org/u/ssfrr)\
**Post date:** [April 2, 2020, 3:54am UTC](https://discourse.julialang.org/t/how-close-is-staticcompile/36880/4 "2020-04-02T03:54:45Z")

</div>

But in the context of making a C-callable shared library it seems like the surface area that might get called at runtime should be pretty manageable, right? You’ll presumably need to write a small C wrapper anyways that takes care of some of the julia initialization and has a specific set of function calls it exposes, with known types. I guess there could be issues if you have some dynamic dispatch that might invoke the compiler for some input values and not others, but if the code is pretty type-stable it seems like that should be doable, right?

---

<div class="post-metadata">

**Author:** ![Oscar\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oscar_smith/32/25343_2.png) [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)\
**Post date:** [April 2, 2020, 3:56am UTC](https://discourse.julialang.org/t/how-close-is-staticcompile/36880/5 "2020-04-02T03:56:29Z")

</div>

Yeah, that should work. That wrapper is an example of the type of test suite I was talking about.

---

<div class="post-metadata">

**Author:** ![tkf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tkf/32/17635_2.png) [@tkf](https://discourse.julialang.org/u/tkf)\
**Post date:** [April 2, 2020, 5:46am UTC](https://discourse.julialang.org/t/how-close-is-staticcompile/36880/6 "2020-04-02T05:46:38Z")

</div>

> [@peter.wolf](#):
>
> I think engineering will balk at the 200mb size

Was that the only problem? For example, didn’t they complain that `libjulia` completely swallows SIGINT (and so ctrl-c stops working)? [Limitations — PyJulia 0.6.1 documentation](https://pyjulia.readthedocs.io/en/latest/limitations.html#ctrl-c-does-not-work-terminates-the-whole-python-process)

---

<div class="post-metadata">

**Author:** ![peter.wolf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/peter.wolf/32/6018_2.png) [@peter.wolf](https://discourse.julialang.org/u/peter.wolf)\
**Post date:** [April 3, 2020, 2:25pm UTC](https://discourse.julialang.org/t/how-close-is-staticcompile/36880/7 "2020-04-03T14:25:44Z")

</div>

I haven’t shown it to them yet. Thanks for the warning 🙂
