I actually don’t think the learning curve for Julia is too bad, but I don’t think there’s an obvious single place for someone to go and start climbing that curve effectively. The manual is far to Reference oriented, there is no “official set of getting started tutorials” linked from the julialang.org front page that would help someone who’s like a biologist with no programming experience, or a second year engineering student who doesn’t want to do something with Matlab for their final project or whatever.
7 Likes
That sounds like task of books like Tanmay Teaches Julia for Beginners: A Springboard to Machine Learning for All Ages and Julia as a Second Language rather than something needed inside official reference manual. And with a lot of video tutorials online you don’ t even need to read a book. Have you seen Get started with Julia ?
3 Likes
DNF already covers my broader opinion so I won’t reiterate that, though I do agree in one small way: I wish function blocks were the only way you could make a function, make it fn if that’s too much to type. Again, too late to remove features, and a major revision would be terrible.
The more specific section is Division functions.
Those “11 division functions” actually included modulo among other things. You could build equivalents from a stripped down set of functions, but since they’re not actually fundamental you would not be able to optimize by saving steps. These functions exist because they’re efficient and useful, and it’d be bad to force users to reimplement them.
The docstring for log(b, x) states:
If
bis a power of 2 or 10,log2orlog10should be used, as these will typically be faster and more accurate.
You’ll find good reasons for having functions around if you look, and these functions are standard for numerical packages, not a quirk of Julia.
12 Likes
I too think having a high-quality official onboarding tutorial is very important. I’ve mention this before, but it bears repeating in this context: the Svelte tutorial is by far the best official online tutorial I’ve seen for any programming language or package. (Svelte is a Javascript framework for reactive UI programming similar to React, but faster and simpler without all the boilerplate - much like Julia.) The tutorial is friendly, attractively designed, declares its prerequisites upfront and eases you into new concepts gently but still fast enough that you can complete it in an hour or two. It relies heavily on interactive illustrative mini-problems, so an online Julia version may have to wait until Julia works reliably with WebAssembly.
In the meantime though, it would be great if Julia had a downloadable interactive tutorial like this with a custom sysimage for instant startup. I don’t think it matters if it’s bloated to a few hundred MB, as long as it’s click-to-run, fast and nearly latency-free. I’d love to help design something like that…
6 Likes
This is in the first paragraph of Zygote’s docs.
With Zygote you can write down any Julia code you feel like – including using existing Julia packages – then get gradients and optimise your program.
This is a blatantly inaccurate claim. In fact, this forum is littered with questions about errors coming from taking gradient of functions that mutate arrays.
6 Likes
That’s clearly a mission statement. They should rephrase that as “The goal of Zygote is that you can write down any Julia code…”
4 Likes
I just came across this article from 1991 (*) about Lisp’s relative lack of success compared to C, despite all of its advantages (speed comparable to C amongst other).
https://www.dreamsongs.com/RiseOfWorseIsBetter.html
What’s troubling is all the similarities with Julia : Lisp aims for “the right thing”, corresponds to the “MTI approach” in this article (in opposition, C is the “good enough” language), targets AI applications, and it is a well-know fact that it has greatly inspired Julia. And lastly, despite all the greatness from Lips, it didn’t get widespread.
One key takeaway is that being good enough for most of users and being easily shippable are the main driving factors to get widespread. (To me, it makes a lot of sense, please refer to the article if you need to be convinced more.)
And again, this article was from 1991 (!). And yet it fits very well with the spread of Python (shipped with all macs & PCs since ages) and Javascript.
What are the two most used programming languages ?..
That’s why I feel 1.10 is great for Julia, for TTFX is reduced even more, error messages are much more readable and useful (thanks to JuliaSyntax.jl), and I’m hopeful for the future.
Yet, there’s some threats that remains. To get a good understanding of internals in order to reach the advertised performances is one of them (following the complexity consideration from the article, Julia is far from being simple in that regards).
And shippability depends (to me at least) on small binaries. Because for now, the fact that other peoples are not using Julia is prevening its use on a professional level: you, as a professional, need the guy (or the girl) on the other side to be willing to install Julia … or download a 300Mo+ binary.
(In opposition, in C, you just compile and ship the binary, or you run the Python script directly because it’s already installed)
But I’m repeating myself (through other post), I’m aware that more of a sayer than a doer (partly due to lack of skills), and acknowledge that these points are well in mind of Julia’s core team (“the state of Julia” was a great talk, btw!).
One (big) caveat to all of that is that we are now entering the age of AI, which may radically change all of that.
(*) thanks to the youtuber “The Primeagen”
Edit: typo and clarity
16 Likes
It’s not negative to tell someone what is missing from their docs. Instead, what is negative is keeping this information secret. The documentation will never be fixed unless someone says what is needed.
This is how open source moves.
15 Likes
Only seeing this now, the reason was that Documenter had no way at the time to control how exactly our examples were rendered. We cannot use the display system directly, writing images inline into the html page like most other docs creating plots does because, for example, we need to gather the images for overview pages. We’re still not fully happy with how the system is set up though and will probably have to change it again one way or another in the future…
I actually thought scatter was one of the better ones 
It has quite a few examples at least. But we can always improve if people file clear issues or preferrably doc PRs.
3 Likes
For hobbyists, it’s usually more fun to make a project, see it working for yourself, then leave, and even if the author is willing to work on documentation for others, they usually know the ins and outs of their own package that they’d implicitly fill the gaps in their documentation, leaving them thinking they’ve documented everything. Projects with a single author or a few authors can run into this issue. Since Julia usually works by combining multiple independent modules, chances are some modules are small, perhaps written by a single author who finds it working on his/her computer, from his/her perspective, from his/her use case. Maybe module A was intended to be combined with module B and C, but was instead composed with a custom module. So, the issue with composability is that it works well enough to be composed in various ways, but not well enough to do so without issues.
It might help to wait until scoped export lands and then have a CI checker to ensure that every public method and type is documented, so we wouldn’t have to rely on individual users to detect undocumented API.
1 Like
If we’re talking about people/programmers “at large”, they do not care about languages. They care about solving problems. And to be very clear about the level of abstraction when I talk about “problems” and “solving” – I mean solutions that make lives easier and/or make them money. They don’t care about languages and algorithms and clever ideas.
What such a person seeks is tools, and a language is a quite primitive tool – it requires relatively high skill to wield well. Well-packaged libraries (can be used without understanding the internals) that compose are much easier to adopt and use, and so the size and effectiveness of the toolbox maps directly to the depth and breadth of the ecosystem (with clean lines separating distinct tools for easier decision-making).
Consider for a moment how “blindly” (I say this with no judgement!) the average Python/Javascript programmer pulls in libraries and glues them together. That kind of ease of use is what it takes for an ecosystem to “scale”. That ease of use is also what allows advanced beginners to flood the internet with tutorials for novices – recommendations which don’t need careful thinking or a deep analysis of the context, but can be applied without too much understanding.
With that perspective, I think the best way for Julia to scale would be to target a burgeoning niche that is currently under-served, and grow the ecosystem to a level of maturity where it helps people solve their problems. And do this repeatedly in multiple niches. As the niches grow, the number of people using Julia in those niches will grow, and there will be positive spillover effects for the language ecosystem. If the field is mature, existing solutions are likely “good enough” and feature rich to an extent that makes it hard for any upstart ecosystem to convert already satisfied users. (It is possible to look back and identify what niches helped other languages in the past, and how the scale of the niche drove the success of the language)
So the key question is: What might be some niches (especially non-academic) that hold potential, and how can we improve the Julia ecosystems in those fields in a targeted manner? Just a few off the top of my head:
- SciML seems like a growing niche where Julia has found “product market fit”.
- Machine learning could have been / could still become one such niche where Julia is appropriate, but that also happens to be very competitive in how much sponsored engineering effort goes into alternatives.
- Finance seems like another niche. The practical challenge is that finance companies are typically reluctant to share much. If they could be induced to share code that doesn’t directly relate to their proprietary market advantage that might create a virtuous cycle for the ecosystem.
- CAD tooling seems like an intriguing niche. There is a great diversity in problems, and there is clearly a market for expensive proprietary solutions. I suspect that it might be a good fit for Julia, piggy-backing on a robust SciML ecosystem. Cedar EDA is an example, but I haven’t heard much since the project was announced. Nothing stops us from looking at the typical problems and available solutions in each engineering sub-field (construction, automotive, analog circuits, digital circuits, control systems, etc – esp. growing niches like space) and thinking about how a Julia-based solution might help move the field forward.
- Applied biology is again a field that’s ripe to grow (beyond just pharma – which Pumas is already focusing on), driven by recent science/tech breakthroughs. As an example, there are presumably folks cobbling together code in Python/R – can we build tools that abstract away details they don’t want to concern themselves with?
- Visualizations: I haven’t delved into Makie much, but is it perhaps at a level where it can give other mature solutions a run for their money, along any axis? The challenge of course is that people prefer to generate visualizations in the same language that they perform analyses in. But if Makie becomes compellingly better in some ways, it might make sense to interface with it from other languages using wrappers (eg: Plotly)
I’m sure Julia Computing has analyzed this question quite a bit; it would be interesting to hear any perspectives from there.
PS: The ongoing work on fixing language fundamentals is of course an important priority, since it serves as a healthy platform for all the above.
PPS: It’s likely some of the examples I’ve mentioned have independently popped up earlier in the thread, but I haven’t closely read through all the posts so forgive me for not citing them 
13 Likes
Nice pun 
2 Likes
I think it’s clearly both a cause and an effect. Clearly Google wouldn’t have created TensorFlow if nobody used Python at all, but also, I doubt Python would be the biggest language for ML if TensorFlow and PyTorch didn’t exist.
What “Why hasn’t Julia gotten any corporate funding?” questions are really asking “Why hasn’t Julia gotten any corporate funding, despite being about as popular as R, Fortran, or Matlab?” If you go by new lines of code for Github projects or popularity on the SO developer survey, Julia is similarly popular to all these languages, and all of them have packages maintained by big companies.
But looking through their Github orgs, there are exactly zero Julia packages being maintained by Meta, Google, or Apple. Not 50% less–zero. And Google just invested $10 million into Modular, whose main product is a nonexistent programming language. And it’s also launched 2 other major programming languages–Kotlin and Go–so it’s not exactly like this is a fluke.
It’s not that every programming language ecosystem is launched completely from scratch by corporations. But the way things are supposed to work is that when you start a new programming language, you work on improving its ecosystem until it gets decent and clears the first few hurdles. At that point, larger companies start taking a closer look and going “OK, this could be a useful tool for us, as long as we put some resources behind developing the ecosystem a bit more.” (Larger companies being more capable of internalizing those externalities; maintaining an ecosystem doesn’t make sense for small companies where only a few people are using that language.)
But that step seems to have broken down somewhere for Julia. Julia has one of the biggest admired (useful according to users) vs. desired (hype, well-regarded by nonusers) gaps of any programming language in the 2023 StackOverflow survey. For some reason, companies are unusually averse to using or contributing to the Julia ecosystem.
And I think this undercuts your own point:
If Python for ML is actually C++ for ML, there’s no problem at all. Meta could create Julia for ML very easily, with very low costs, by just wrapping the C++ code. There’s clearly no need to rewrite 100% of all code in the world to use Julia; we’re all happy using BLAS, even though it’s all Fortran. So why doesn’t Meta do anything like that?
11 Likes
I have been searching for jobs in the private sector for a while and a lot of data scientist positions rarely ask for knowledge of Julia.
Are you claiming that Julia, R, Fortran and Matlab have equal numbers of users? Within industry, that claim seems false to me – for example, R is somewhere between 100x and 1000x more popular from what I’ve seen in industry. I suspect this claim is false in academia as well, although perhaps only by 10x. But if you’re not making the claim of equal popularity, what does “as popular as R” mean to you?
I don’t understand several points in your argument here:
- How much Matlab code is maintained by those companies? How much Fortran code? If that’s zero, why would this metric you’re citing be diagnostic for niche languages?
- Modular’s public product and what it tells VC’s may be very different – unless you’ve been involved in their funding talks with Google, it seems risky to reason about the motives for Google’s investments.
- Kotlin was made by JetBrains, not Google, right? And Kotlin had 6 years of being backed by a famous Java company before Google adopted it officially, no?
I would recommend talking to PyTorch devs like Soumith or Edward to get their views on this topic rather than speculating about their motives.
1 Like
I feel the toolchain to wrap cpp isn’ t easy enough in julia. I’m considering adding julia support to autopybind11 / autopybind11 · GitLab so people can generate py/julia bindings for cpp at the same time.
12 Likes
But I often see some positions have descriptions like: ‘Experience with scripting languages like R, Python, (add other languages).’
For me, it is an indication that the tool doesn’t matter for that position, and even if Julia is not mentioned in the description, between lines, it looks like it is completely possible to use it.
Grant Sanderson did a great job on this.
1 Like
There are some ML fields, which can be nice entry points for Julia users. For instance, there is a lot of interest and development in LLMs now. In my opinion many current libraries have a two-language problem/barrier and also installation isn’t that straightforward. Some focused development in this field (see for instance langchain and laama.cpp - there are already some Julia implementations) could be a driver for increased Julia popularity.
After all, the Julia package management is great. Of course it would be even better if we had a easy/fast way to create binaries of reasonable size…
Also, I think that Blink.jl is underrated - it makes it really easy to create nice GUIs for Julia apps - better than the Python in my experience.
2 Likes