Perhaps counterintuitively, it’s great for a programming language to have significant roadblocks. For just a moment, I want you to imagine a hypothetical perfect programming language. Perfect in the sense that it has such great expressive power, and it is so extensible, that anyone can easily bend it to their taste. It lacks your favorite, deal-breaker feature X? Spend a couple of hours, et voilà! You’re good to go. Now, you’re free to pick any name you want for your imaginary language. If, by any chance, you named it Lisp, someone already used their time-travelling machine, went back in time, and wrote an article on how
Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp.
Hard problems call for a lot of careful thinking and planning ahead. Very hard problems call for (and thus foster) collaboration. Julia, to me, is uniquely posited in the programming language space. It is very expressive, extensible, comes with a powerful REPL, built-in reflection, and features that promote composability throughout the ecosystem. At the same time, some programming language design decisions (type system, multiple dispatch as the centerpiece, etc.) have given birth not only to great language features, but also problems that we need to figure out how to deal with.
At a more meta level, the community seems to me to be one of the most welcoming communities out there (admittedly anecdotal), and that serves as a catalyst to greatly amplify programmer throughput and accelerate language/ecosystem development. The people that ultimately decide on the shape of the language understand the importance of patiently waiting to see how a proposed feature will play out, instead of rushing to reach a consensus (refer to, e.g., lack of built in interface support). They also recognize that one should be biased against adding new features to the language core, also something very significant for a healthy, long-lived programming language.
I often come across people complaining about how the Julia userbase is “mostly scientists” instead of “tried and true software engineers”, and how that’s the reason [Julia lacks X | is bad at Y]. First, I’d argue that there are several excellent hackers active in Julialand. Second, the fact that language (and package) designers often have to build a solution that caters to non-programmers naturally leads into adopting a user-centric design approach, avoiding the common pitfall of building cool, but underused shiny toys to be put away in a box and gather dust. Third, I’d argue that the ratio of highly capable developers over total users is quite high, I’d posit quite higher than in, say, JS or Python. Why is that? Well, programming in Julia has been described as “very fun” (why that is is another topic for discussion on its own). Not everything in the design space is set in stone, people have the ability to give form to a cool programming language. The language attracts tinkerers, be it people with expertise in string manipulation, people that build compilers for quantum computing, or astrophysicists. It is a very diverse pool of highly passionate individuals.
I’m writing all of this off the top of my head to further drive home that it’s very hard to put in words how well a programming language is doing, and taking a look at GitHub stars barely scraps the surface. A lot of the (biased) language users intuitively feel that it’s doing great, and that there’s a very bright future ahead.
It’s not just Julia either. There hasn’t been a better time in programming history to challenge the status quo and experiment with less widely used programming languages. Maybe people who appreciate the composability of Julia would really like the OCaml module system. There’s Zig, Odin, Jai, Roc, Gleam, Elixir is getting better LSP, the list goes on and on and on. In fact, several aspects of Julia were inspired by how well (or terribly bad) features of other languages worked out. Other niche languages, and very widespread languages too. As an example, Scoped Values were inspired by Java. People thinking hard about bringing structured concurrency to Julia study Swift, Java, Kotlin, and other, more exotic frameworks. Others, who want to improve task cancellation are inspired by .NET. I’ll directly quote @mbauman:
Julia is a great tool that I enjoy using. My Milwaukee M18 Oscillating Multi-Tool is also a great tool that I enjoy using. But I don’t go around looking for things to cut holes into because I want to use the thing. And I don’t use it to whack on nails.
At the end of the day, programming languages are a tool. A tool that if selected and used diligently, accompanied by a lot of introspection, can greatly transform the very ways you think, and that’s not just limited to writing better software. Instead of worrying whether X tool will be used in Y company Z years from now, I much rather focus on how using it made me a better thinker. Julia did just that. I now appreciate type-driven design a lot more, for instance, or applying ideas from the functional world to the code that I write. These ideas aren’t even inherently linked to Julia; rather, using Julia made me appreciate (or wish for) ideas introduced in other programming languages. So go out there, see what sticks, and have fun along the way! Playing around with Julia on your journey comes with the added benefit of interacting with the wonderful community, and maybe, just maybe, you’ll come out of this not only a better thinker, but a more compassionate human being. At least I did.