# Is my understanding of Julia correct?

**URL:** <https://discourse.julialang.org/t/is-my-understanding-of-julia-correct/76924>\
**Category:** New to Julia\
**Tags:** question\
**Created:** [February 22, 2022, 5:29pm UTC](https://discourse.julialang.org/t/is-my-understanding-of-julia-correct/76924 "2022-02-22T17:29:50Z")\
**Posts on this page:** 1\
**Showing post:** 18

<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:** [February 23, 2022, 3:28am UTC](https://discourse.julialang.org/t/is-my-understanding-of-julia-correct/76924/18 "2022-02-23T03:28:07Z")

</div>

> [@ckfinite](#):
>
> One topic that I’m not sure has been discussed about type stability is that some relatively simple optimizations (polymorphic inline caching, in particular, and dispatch stubs more generally) may be able to dramatically improve performance of type unstable code and stave off the need for full inference and compilation.

I think what people call “mutate-or-widen” approach may be somewhat relevant: [Tail-call optimization and function-barrier -based accumulation in loops](https://discourse.julialang.org/t/tail-call-optimization-and-function-barrier-based-accumulation-in-loops/25831). A similar idea is applied to [[ANN] Catwalk.jl - With dynamic dispatch to the moon! (an adaptive optimizer, aka JIT compiler)](https://discourse.julialang.org/t/ann-catwalk-jl-with-dynamic-dispatch-to-the-moon-an-adaptive-optimizer-aka-jit-compiler/57917)

I call the generalized version of it a “tail-call function-barrier” approach and use it extensively in JuliaFolds to help type-stability of otherwise unstable `for` loops (and iterations in general). But, more importantly, I think this approach is particularly attractive because even unstable code _dynamically type-stabilizes_. I think this approach is an example that demonstrates the dynamic-_and_-efficient aspect of Julia.

That said, using this principle in practice is very manual and cumbersome at the moment. JuliaFolds hide the complexity in many cases. But I’ve been wanting to play with the compiler to make it more automatic.

> [@Elrod](#):
>
> I don’t think that poses any limitations on the REPL

Even Haskell and nowadays even C++ have REPL. So, I agree that REPL would be a blocker. It’s a bit tangent, but, rather, I think the important aspect is that we can freely write “broken” code easily (which is the greatest strength of dynamic languages; extremely rapid feedback). Interestingly, Haskell has [`-fdefer-type-errors`](https://gitlab.haskell.org/ghc/ghc/-/wikis/defer-errors-to-runtime) for “disabling” type check and also I’ve heard Roc language tries to incorporate this idea more seriously. Perhaps dynamic and static languages meet in the middle in the future. On the dynamic language side, there are examples like Python which has mypyc project for compiling type-annotated code. But I think Julia is a very rare case where the optimizability of dynamic code has been the design goal from the getgo. I guess it’s reasonable to hope there is a “static sub-language” in Julia waiting to be discovered.

> [@Akatz](#):
>
> I know @jpsamaroo and @tkf are into the JET/ dynamic semantics side of things

Just to be clear, I’m not at all against defining sub-language that is statically compiled and possibly executable without runtime. My main comment has been clarifying the _current_ status of Julia as a language, especially on what is (not) guaranteed. (But I personally like playing with “dynamic but optimizable semantics” and so I may be exaggerating this aspect.)

---

_[View the full topic](https://discourse.julialang.org/t/is-my-understanding-of-julia-correct/76924)._