# Suggestion: introduce something like a @inferable or @typestable macro to the language

**URL:** https://discourse.julialang.org/t/suggestion-introduce-something-like-a-inferable-or-typestable-macro-to-the-language/86042
**Category:** Internals & Design
**Created:** [August 19, 2022, 8:45pm UTC](https://discourse.julialang.org/t/suggestion-introduce-something-like-a-inferable-or-typestable-macro-to-the-language/86042 "2022-08-19T20:45:48Z")
**Posts on this page:** 1
**Showing post:** 26

<div class="post-metadata">

### Author: ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)
#### Post date: [August 20, 2022, 4:41pm UTC](https://discourse.julialang.org/t/suggestion-introduce-something-like-a-inferable-or-typestable-macro-to-the-language/86042/26 "2022-08-20T16:41:55Z")

</div>

> [@zp3](#):
>
> Referring to the talk of Jeremy Howard ([https://youtu.be/s6pjxCuNGjc](https://youtu.be/s6pjxCuNGjc)) at JuliaCon, I support his opinion that one of the main drawbacks of the language is the difficulty of creating static executables which are small in size and comparable with C or Fortran binaries.

Note possible, (large) binaries that support all Julia code; also with a different approach tiny binaries:

> Since we’re only including what we need, binaries can be quite small (e.g. 8.4K for Hello World)

I’m trying to me mindful of: [We as a community should be more understanding of Julia's flaws](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030)

So, note, that’s an exception, but since I think the small binary, as opposed to just binary option, is overblown, I’ll not take much time explaining, the limitations and potential workarounds.

> I think JIT is not necessary for the actual final executable

Yes, the JIT is handled by LLVM, and the LLVM (Julia’s largest dependency at 79MB + 41M (libjulia-codegen) = 120 MB, besides the sysimage at 221M, that can be made smaller, 4th largest at 32MB OpenBLAS can be dropped) can be excluded as of just released Julia 1.8.0. From its NEWS:

> The LLVM-based compiler has been separated from the run-time library into a new library, `libjulia-codegen`. It is loaded by default, so normal usage should see no changes. In deployments that do not need the compiler (e.g. system images where all needed code is precompiled), this library (and its LLVM dependency) can simply be excluded ([#41936](https://github.com/JuliaLang/julia/issues/41936)).

and:

> New option `--strip-ir` to remove the compiler’s IR (intermediate representation) of source code when building a system image. The resulting image will only work if `--compile=all` is used, or if all needed code is precompiled ([#42925](https://github.com/JuliaLang/julia/issues/42925)).

See more links here:

> [@Wrap Julia package in Python: which is the best option?](https://discourse.julialang.org/t/wrap-julia-package-in-python-which-is-the-best-option/79344/14):
>
> There’s one more new option. Not sure It’s been announced, but it installs from Python (and its Julia sub-module TyPython.jl was recently registered too): That should work for all Julia code (also juliacall, part of PythonCall.jl). There’s also, but still only for special Julia code: one of its limitations: Doesn’t currently work on Windows. and building on it (with same (above) limitations): Calling compiled Julia library from Python

---

_[View the full topic](https://discourse.julialang.org/t/suggestion-introduce-something-like-a-inferable-or-typestable-macro-to-the-language/86042)._