# Can juliac increase julia adoption?

**URL:** <https://discourse.julialang.org/t/can-juliac-increase-julia-adoption/127838>\
**Category:** General Usage\
**Tags:** question\
**Created:** [April 8, 2025, 11:15am UTC](https://discourse.julialang.org/t/can-juliac-increase-julia-adoption/127838 "2025-04-08T11:15:22Z")\
**Posts on this page:** 20\
**Page:** 3

<div class="post-metadata">

**Author:** ![gdalle](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gdalle/32/224680_2.png) [@gdalle](https://discourse.julialang.org/u/gdalle)\
**Post date:** [April 9, 2025, 5:26pm UTC](https://discourse.julialang.org/t/can-juliac-increase-julia-adoption/127838/41 "2025-04-09T17:26:08Z")

</div>

> [@uwestoehr](#):
>
> Julia is much bigger than FreeCAD as far as I can tell and there should be funding available to setup, maintain and also fill a Wiki.

This is not to say that our documentation is stellar, but what do you mean exactly by “a wiki”?

- An exhaustive reference on how the language works? That’s the [Julia documentation](https://docs.julialang.org/en/v1/)
- A way to learn it quickly? That’s the [learning Julia page](https://julialang.org/learning/)
- A recap of the main development tips? That’s [ModernJuliaWorkflows](https://modernjuliaworkflows.org/)

For all of these, users are welcome to contribute, but I will concede that the contribution bar is high

---

<div class="post-metadata">

**Author:** ![e3c6](https://avatars.discourse-cdn.com/v4/letter/e/e79b87/32.png) [@e3c6](https://discourse.julialang.org/u/e3c6)\
**Post date:** [April 9, 2025, 5:43pm UTC](https://discourse.julialang.org/t/can-juliac-increase-julia-adoption/127838/42 "2025-04-09T17:43:19Z")

</div>

> [@photor](#):
>
> What happened in 2019?

Probably [Announcing the release of Julia 1.0](https://julialang.org/blog/2018/08/one-point-zero/)

---

<div class="post-metadata">

**Author:** ![GHTaarn](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ghtaarn/32/216007_2.png) [@GHTaarn](https://discourse.julialang.org/u/GHTaarn)\
**Post date:** [April 9, 2025, 5:44pm UTC](https://discourse.julialang.org/t/can-juliac-increase-julia-adoption/127838/43 "2025-04-09T17:44:59Z")

</div>

There is a volunteer managed wiki at [Introducing Julia - Wikibooks, open books for an open world](https://en.wikibooks.org/wiki/Introducing_Julia)

---

<div class="post-metadata">

**Author:** ![uwestoehr](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/uwestoehr/32/216201_2.png) [@uwestoehr](https://discourse.julialang.org/u/uwestoehr)\
**Post date:** [April 9, 2025, 6:46pm UTC](https://discourse.julialang.org/t/can-juliac-increase-julia-adoption/127838/44 "2025-04-09T18:46:00Z")

</div>

> [@gdalle](#):
>
> but what do you mean exactly by “a wiki”?

A Wiki where people can directly contribute their knowledge. Take my case: In case I will eventually manage to compile a Julia module to a DLL, I could in a Wiki create a new page and describe step by step how this is done. So Just like editing the Wikipedia.  
In FreeCAD we handle the access to the Wiki the way that people can apply for the access in a forum section and if we see that a user fills the Wiki with spam or bullshit, we block him.

I cannot do the same for [Julia Documentation · The Julia Language](https://docs.julialang.org/en/v1/). Note hereby that the need to use Git o send in PRs etc. is a big hurdle. Only a tiny fraction of the FreeCAD users is used to Git with a Wiki anybody can contribute directly, whenever he has some time and his work is directly visible. I mean the Wikipedia is the best proof of that concept. It would not have been that successful if one would have to use a versioning system.

[Introducing Julia - Wikibooks, open books for an open world](https://en.wikibooks.org/wiki/Introducing_Julia) would be the right way to go, but why is that not linked at [https://julialang.org/](https://julialang.org/) and [Julia Documentation · The Julia Language](https://docs.julialang.org/en/v1/) ? It does not appear in the Julia Blog etc.?

OK, I am just a Julia guest, I cannot tell Julia what it should do, but I can give as feedback that as it is it is not super friendly for average users.  
For example in [Libraries · PackageCompiler](https://julialang.github.io/PackageCompiler.jl/stable/libs.html)  
I would already add info that I learned today in Discourse but I can’t. The next user cannot benefit from better info, would be stuck again and ask probably the same as I did in Discourse. But this way you also block the community by answering the same questions. What I can also state is that the more the FreeCAD Wiki evolved, the less basic questions we had in the forum and could focus more on bugs and development.

---

<div class="post-metadata">

**Author:** ![lmiq](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lmiq/32/18314_2.png) [@lmiq](https://discourse.julialang.org/u/lmiq)\
**Post date:** [April 9, 2025, 7:37pm UTC](https://discourse.julialang.org/t/can-juliac-increase-julia-adoption/127838/45 "2025-04-09T19:37:07Z")

</div>

A good place to share this knowledge is here.

I agree with you (and that has been dicussed before) that some sort of unofficial and community-driven documentation could be a nice addon to the current official documentation. I think there is nothiing preventing anyone from doing it. I have, for example, compiled some stuff [here](https://m3g.github.io/JuliaNotes.jl/stable/) with that in mind. Nevertheless, what is harder is to get **official** (in any way that could mean) support for such efforts, because when something becomes official it requires regular long-term mainteiners, strict correctness, and starts to be a burden on a core of developers that have other priorities.

On the other hand, nobody besides me has any responsibility with the content my notes page, and even I think it got outdated in some places given what I know now about Julia. So this enterprise is hard, and having an official support for it is even harder. We can certainly start a wiki (actually I think there was one at some point). But the people that could contribute the most probably prefer to contribute to the official docs when they can spend time on that, or writting more autoral blog posts.

---

<div class="post-metadata">

**Author:** ![goerz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/goerz/32/3269_2.png) [@goerz](https://discourse.julialang.org/u/goerz)\
**Post date:** [April 9, 2025, 7:38pm UTC](https://discourse.julialang.org/t/can-juliac-increase-julia-adoption/127838/46 "2025-04-09T19:38:15Z")

</div>

> [@uwestoehr](#):
>
> [Introducing Julia - Wikibooks, open books for an open world](https://en.wikibooks.org/wiki/Introducing_Julia) would be the right way to go, but why is that not linked at [https://julialang.org/](https://julialang.org/) and [Julia Documentation · The Julia Language](https://docs.julialang.org/en/v1/) ? It does not appear in the Julia Blog etc.?

If it’s moderately active, it probably _should_ be linked there. But ultimately, the question is what the community naturally gravitates to, and that Wiki just doesn’t seem to get much attention (I wasn’t aware of it). The community seems very much centered on GitHub, Slack, and Discourse. For Slack in particular, there’s a not-so-small subset of the community that would prefer Zulip. So a Zulip community exists, but sees only a tiny fraction of the activity of Slack. There doesn’t seem to be the collective desire / critical mass to move. I fear it might be the same with the Wiki: There’s no critical mass for having significant mindshare. So, while we can set up all these channels, there’s little we can do to “force” people there.

> [@uwestoehr](#):
>
> The next user cannot benefit from better info, would be stuck again and ask probably the same as I did in Discourse

For what it’s worth, Discourse is probably what we have that’s closest to a Wiki. Beyond making PRs to various documentation (which, yes, is a very high hurdle), Discourse is probably the single most important community resource. A lot of knowledge gets collected here, and unlike the Slack communications that disappear after three months, it builds a permanent record. So it’s a good idea to post a summary of what your solution will end up being, as a post here. That way, people will be able to find it relatively easily.

“Real” documentation will probably always be going through pull requests. I would note that the GitHub UI makes changes to a Markdown document relatively easy, _almost_ like a Wiki. But I understand (and agree) that there’s a still a big hurdle for non-technical users.

---

<div class="post-metadata">

**Author:** ![willow](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/willow/32/208918_2.png) [@willow](https://discourse.julialang.org/u/willow)\
**Post date:** [April 9, 2025, 7:56pm UTC](https://discourse.julialang.org/t/can-juliac-increase-julia-adoption/127838/47 "2025-04-09T19:56:28Z")

</div>

I agree there is great potential for Julia to be adopted as backend for Python packages, there are an astonishing number of Python users in every discipline, and Julia has an edge over other backend languages on development time and performance. Because nobody has to learn a new language when they use python interfaces, Python users can experience all of the benefits to using Julia without the usual barriers to entry of learning a new language.

In my experience trying to find Python users for my julia-based tensor processing package, Python wheels and ahead-of-time compilation have been huge barriers to adoption. If Julia could be compiled and shipped like other languages with smaller binaries (\<100MB), it would make a big difference. The great work of [cjdoris (Christopher Rowley) · GitHub](https://github.com/cjdoris) and others developing [GitHub - JuliaPy/PythonCall.jl: Python and Julia in harmony.](https://github.com/JuliaPy/PythonCall.jl) has been critical for me thus far, as multi-language integrations require a lot of effort to make production-ready. For example, consider the headache of packaging Julia dependencies with a python package manager. Multiple Julia integrations require us to resolve different Julia environments at Python import time. [GitHub - JuliaPy/pyjuliapkg: Manage your Julia dependencies from Python](https://github.com/JuliaPy/pyjuliapkg) is an awesome approach given the current capabilities of Julia, but being able to ship a binary might be more broadly applicable.

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [April 10, 2025, 3:21pm UTC](https://discourse.julialang.org/t/can-juliac-increase-julia-adoption/127838/48 "2025-04-10T15:21:57Z")

</div>

This sort of a silly topic for handwringing imo, but do keep in mind that the Venn diagram of Rust users and GitHub users is a circle while the vast majority of Julia users have never even used GitHub. So GitHub stars are unlikely to be a perfect proxy for relative language popularity and growth. In fact, I suspect that this issue affects most language popularity metrics out there—popularity of languages that are used by people whose primary profession is not programming are significantly underestimated. Applies to R, Matlab, Julia, Mathematica, probably Fortran too.

I also don’t believe that Rust adoption is exponential. When you see exponential growth in a quantity that’s inherently bounded—like number of programmers on planet Earth, or number of people using GitHub—what that tells you is that you’re nowhere near the ceiling if you’re still seeing exponential growth. Eventually the exponential will flatten out into a sigmoid. Indeed, it makes sense that there’s way more than 100k systems programmers on GitHub who could potentially star the Rust repo, so it makes sense that they’re not near their ceiling. Do I believe there are fewer GitHub users who would potentially star the Julia repo? Yes. Does that mean that Julia growth in the wider world outside of GitHub is following the same shape? Not really. Maybe, but who knows.

Anyway this is why I think chasing some shape of curve in GitHub stars is not particuarly interesting. Keep making the language better and more useful to more people. That’s the bottom line.

---

<div class="post-metadata">

**Author:** ![GHTaarn](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ghtaarn/32/216007_2.png) [@GHTaarn](https://discourse.julialang.org/u/GHTaarn)\
**Post date:** [April 10, 2025, 3:47pm UTC](https://discourse.julialang.org/t/can-juliac-increase-julia-adoption/127838/49 "2025-04-10T15:47:18Z")

</div>

> [@StefanKarpinski](#):
>
> the Venn diagram of Rust users and GitHub users is a circle while I the vast majority of Julia users have never even used GitHub.

I think that you are right about this, but never the less, the ratio of Julia programmers to Rust programmers is very similar for both Tiobe and Github stars. There can of course be many explanations for this.

> [@StefanKarpinski](#):
>
> I also don’t believe that Rust adoption is exponential.

I’m not as confident as you on this, my impression is that Rust has a lot of momentum right now and if [Tiobe](https://www.tiobe.com/tiobe-index/) is approximately equal to market share then Rust has about 1% now and could easily be on the exponential part of the S-curve to the 20% that C/C++ has. But Rust and Julia have completely different target users, so this is nothing to worry about, the 25% market share that Python, R and Matlab have (according to Tiobe) is still attractive.

> [@StefanKarpinski](#):
>
> Anyway this is why I think chasing some shape of curve in GitHub stars is not particuarly interesting. Keep making the language better and more useful to more people. That’s the bottom line.

👍

---

<div class="post-metadata">

**Author:** ![LaurentPlagne](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/laurentplagne/32/10103_2.png) [@LaurentPlagne](https://discourse.julialang.org/u/LaurentPlagne)\
**Post date:** [April 10, 2025, 5:26pm UTC](https://discourse.julialang.org/t/can-juliac-increase-julia-adoption/127838/50 "2025-04-10T17:26:46Z")

</div>

The following two arguments for `juliac` have already been expressed elsewhere, but since I have encountered them personally, let me express them once again:

- You want to distribute commercial licenses for closed-source software developed in Julia: juliac should allow you to distribute binary libraries or executables (with a reasonable size) without disclosing the source code.
- You want to promote Julia usage in a large company by providing a Julia software component as a binary library to be integrated into a larger system of code (typically developed in C++): people in charge of integrating this new component do not have to know about the programming language used. If the component is successful, you may advertise the productivity, efficiency, and joy you experienced while programming it in Julia 🙂

Considering these two situations, I believe that `juliac` can help extendind Julia adoption out of the academic world.

---

<div class="post-metadata">

**Author:** ![paulmelis](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/paulmelis/32/35063_2.png) [@paulmelis](https://discourse.julialang.org/u/paulmelis)\
**Post date:** [April 10, 2025, 7:28pm UTC](https://discourse.julialang.org/t/can-juliac-increase-julia-adoption/127838/51 "2025-04-10T19:28:31Z")

</div>

> [@LaurentPlagne](#):
>
> Considering these two situations, I believe that `juliac` can help extendind Julia adoption out of the academic world.

How about the third situation of simply wanting to distribute - in binary - a tool for others to use, even when the source code is open? I think it helps to separate the impact of Julia-written tooling for end-users versus impact on developers writing in Julia.

These days I encounter new and modern tools getting (re-)written in Rust all the time, the latest one the [uv](https://github.com/astral-sh/uv) Python package manager some time ago, as a replacement for pip and friends. I don’t care about the open-source Rust code directly, but I **do** appreciate that it’s fast mostly because it was written in Rust to begin with. I.e. it helps in cementing Rust’s reputation as a “fast language” even more.

The Linux x86\_64 binary release of uv is an executale of a whopping 41 MB, but that’s mostly irrelevant as it’s distributed as a single binary that will run out-of-the-box. Now that’s convenient! Julia could offer single-binary tools just like that, is my feeling, if `juliac` gets a bit more attention and becomes a standard part of the Julia distribution. That might help in getting some more tools written in Julia distributed to folks that otherwise would not get exposed to it.

---

<div class="post-metadata">

**Author:** ![minetest2048](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/minetest2048/32/45961_2.png) [@minetest2048](https://discourse.julialang.org/u/minetest2048)\
**Post date:** [April 10, 2025, 9:27pm UTC](https://discourse.julialang.org/t/can-juliac-increase-julia-adoption/127838/52 "2025-04-10T21:27:11Z")

</div>

Adding to this it will be nice if `juliac` can grow to point where we can write `juliaup` in julia instead of rust

---

<div class="post-metadata">

**Author:** ![The\_Mastermage](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/the_mastermage/32/49444_2.png) [@The\_Mastermage](https://discourse.julialang.org/u/The_Mastermage)\
**Post date:** [April 11, 2025, 3:37am UTC](https://discourse.julialang.org/t/can-juliac-increase-julia-adoption/127838/53 "2025-04-11T03:37:59Z")

</div>

For me one of the best arguments for Julia and against Python is the Julia build in Package Manager which can already deal with environments and we have Yggdrasil.jl to distribute binaries. Which removed the ned for me to figure out if I use pip, env pipenh, venv, conda, anaconda, microconda, Miniforge, mambaforge, pixie, pdm, poetry … because I can always just go into the Julia terminal hit tab and switch to package managing.

---

<div class="post-metadata">

**Author:** ![e3c6](https://avatars.discourse-cdn.com/v4/letter/e/e79b87/32.png) [@e3c6](https://discourse.julialang.org/u/e3c6)\
**Post date:** [April 11, 2025, 8:27am UTC](https://discourse.julialang.org/t/can-juliac-increase-julia-adoption/127838/54 "2025-04-11T08:27:55Z")

</div>

One has to admit that Python has gotten nicer in that regard now, with things like `uv` / `pixi`.

Thought nothing beats yet how nice it is to install `CUDA` in Julia, at least in my experience.

---

<div class="post-metadata">

**Author:** ![The\_Mastermage](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/the_mastermage/32/49444_2.png) [@The\_Mastermage](https://discourse.julialang.org/u/The_Mastermage)\
**Post date:** [April 11, 2025, 2:10pm UTC](https://discourse.julialang.org/t/can-juliac-increase-julia-adoption/127838/55 "2025-04-11T14:10:24Z")

</div>

While I have to agree on pixie and uv, which are amazing tools it’s still not as convenient as boom installed Julia with everything I need built in.

---

<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:** [April 11, 2025, 4:50pm UTC](https://discourse.julialang.org/t/can-juliac-increase-julia-adoption/127838/56 "2025-04-11T16:50:46Z")

</div>

This is one of those open-ended topics that can meander widely and unendingly… and is prone to hot-takes, xkcd#386-style responses, and can easily lead to flamewars that can feel exclusionary. I’m not saying that’s happening here or that anyone is too close to thin ice! But I can see some thin ice lurking out there further in the distance and don’t want anyone to fall in. 🙂

We’ve had a good discussion here over the past few days, and I love all the excitement about juliac! Let’s just plan on bringing things to a close soon. Any subsequent discussion beyond that can be focused in more narrowly scoped topics if anyone here cares to open them.

---

<div class="post-metadata">

**Author:** ![barrettp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/barrettp/32/18259_2.png) [@barrettp](https://discourse.julialang.org/u/barrettp)\
**Post date:** [April 12, 2025, 3:48pm UTC](https://discourse.julialang.org/t/can-juliac-increase-julia-adoption/127838/57 "2025-04-12T15:48:47Z")

</div>

The problem that we are beginning to see in astronomy is that the ground- and space-based observatories that will come online in the next few years, such as the Rubin Observatory, the Roman Observatory, and the Next Generation VLA (assuming they are not cancelled); will generate petabytes of data per year. Scientific Python (i.e., Numpy, including Numba and JAX) does not have the performance to process this data volume. This will suppress the quality of the science that can be achieved. As a result, the JuliaAstro community is working hard to advertise the benefits of Julia over Python. The people that I have spoken to just assume that Julia is another run-of-the-mill programming language. When I tell them of its benefits over Julia, particularly that you can compile directly to GPU code, they are mildly impressed, and some have shown an interest in using it. The problem that we currently have is the lack of packages and applications to support astronomical data analysis. In summary, the big issue in my opinion is cultural, and not technical. and Python currently dominates the scientific data analysis culture.

---

<div class="post-metadata">

**Author:** ![ohmsweetohm1](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ohmsweetohm1/32/49126_2.png) [@ohmsweetohm1](https://discourse.julialang.org/u/ohmsweetohm1)\
**Post date:** [April 13, 2025, 6:58am UTC](https://discourse.julialang.org/t/can-juliac-increase-julia-adoption/127838/58 "2025-04-13T06:58:54Z")

</div>

> [@LaurentPlagne](#):
>
> You want to distribute commercial licenses for closed-source software developed in Julia: juliac should allow you to distribute binary libraries or executables (with a reasonable size) without disclosing the source code.

Our workflow for that is to build an app with PackageCompiler.jl and then, to get around the relocatability issue, build a docker image with that. It is not a stand alone binary but at least runnable on other machines.

---

<div class="post-metadata">

**Author:** ![LaurentPlagne](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/laurentplagne/32/10103_2.png) [@LaurentPlagne](https://discourse.julialang.org/u/LaurentPlagne)\
**Post date:** [April 13, 2025, 7:11am UTC](https://discourse.julialang.org/t/can-juliac-increase-julia-adoption/127838/59 "2025-04-13T07:11:01Z")

</div>

Thanks for the tip !

We did consider this, but we weren’t sure about the reverse engineering issues ([link](https://discourse.julialang.org/t/best-practice-using-packagecompiler-jl-or-something-else-for-code-obfuscation-and-extensibility/85806/2)). I believe I recall Jeff Bezanson mentioning this topic while presenting the work on `juliac`, and I guessed that it might offer a proper solution to the source confidentiality issue.

---

<div class="post-metadata">

**Author:** ![Marco\_Antoniotti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/marco_antoniotti/32/18697_2.png) [@Marco\_Antoniotti](https://discourse.julialang.org/u/Marco_Antoniotti)\
**Post date:** [April 13, 2025, 6:38pm UTC](https://discourse.julialang.org/t/can-juliac-increase-julia-adoption/127838/60 "2025-04-13T18:38:23Z")

</div>

Oh come on! You know what else to complain about. 😀  
`struct`’s that do not have a `:include` option? (Yes: note the keyword syntax) Macro calls that have `@` in front? (Ok, this is low!)

Cheers

Marco

[Previous page](https://discourse.julialang.org/t/can-juliac-increase-julia-adoption/127838.md?page=2)

[Next page](https://discourse.julialang.org/t/can-juliac-increase-julia-adoption/127838.md?page=4)