This is not to say that our documentation is stellar, but what do you mean exactly by “a wiki”?
For all of these, users are welcome to contribute, but I will concede that the contribution bar is high
Probably Announcing the release of Julia 1.0
There is a volunteer managed wiki at Introducing Julia - Wikibooks, open books for an open world
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. 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 would be the right way to go, but why is that not linked at https://julialang.org/ and Julia Documentation · The Julia Language ? 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
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.
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 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.
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.
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.
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 and others developing GitHub - JuliaPy/PythonCall.jl: Python and Julia in harmony. 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 is an awesome approach given the current capabilities of Julia, but being able to ship a binary might be more broadly applicable.
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.
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.
I’m not as confident as you on this, my impression is that Rust has a lot of momentum right now and if Tiobe 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.
The following two arguments for juliac have already been expressed elsewhere, but since I have encountered them personally, let me express them once again:
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 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.
Adding to this it will be nice if juliac can grow to point where we can write juliaup in julia instead of rust
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.
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.
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.
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.
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.
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.
Thanks for the tip !
We did consider this, but we weren’t sure about the reverse engineering issues (link). 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.
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