# Is there a strong case that Julia is a more composable language?

**URL:** <https://discourse.julialang.org/t/is-there-a-strong-case-that-julia-is-a-more-composable-language/118554>\
**Category:** General Usage\
**Tags:** question, python\
**Created:** [August 24, 2024, 10:26am UTC](https://discourse.julialang.org/t/is-there-a-strong-case-that-julia-is-a-more-composable-language/118554 "2024-08-24T10:26:33Z")\
**Posts on this page:** 1\
**Showing post:** 11

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [August 25, 2024, 5:08am UTC](https://discourse.julialang.org/t/is-there-a-strong-case-that-julia-is-a-more-composable-language/118554/11 "2024-08-25T05:08:31Z")

</div>

> [@Benny](#):
>
> The obstacles in such glue languages comes with the 2-language problem:

This is — itself — a reason for Julia’s composability. Every Turing complete language can implement _any_ features from any other language… except performance.

I think that having user defined structs and functions as capable and performant as language “builtins” is a big part of the composability story. Multiple dispatch helps but I wouldn’t dismiss performance. As Jeff says, [“performance is actually special”](https://discourse.julialang.org/t/julia-vs-r-vs-python/4997/90).

---

_[View the full topic](https://discourse.julialang.org/t/is-there-a-strong-case-that-julia-is-a-more-composable-language/118554)._