Generally it is best to do something like
struct Foo{T<:SMatrix{3,3,Float64}}
bar::T
end
where dropping SMatrix or its type parameters may actually be not only innocuous, but advantageous. If T needs to be checked, that can be done in the constructor.
I can confirm this. It’s some time since I worked with economists, but I have the occasional project with them. The last small conference I attended some months ago, about half the presentations (in energy economics/markets) used julia.
“At present, Julia is an overlooked programming language.”
There is so much effort going into how to make Python faster with multi-threading and all sorts of JIT compilation with or without static typing, that Julia seems to be a screaming solution. It can also call many other libraries written in other languages, so the ecosystem isn’t as small as people make it to be? Python is borrowing from other languages all the time and calling it their ecosystem! And, approximately 73% to 75% of the Python package ecosystem was developed in the last five years [source: Gemini]. That doesn’t seem to be out of reach for Julia, especially given AI-assisted development possibilities.
The weak point in the argument is the suggestion that Julia could close the ecosystem gap quickly just because AI makes package creation easier.
I do not think that follows.
First, an ecosystem is maintained libraries, stable APIs, docs, tests, CI, issue triage, version compatibility, community trust, downstream integration, and people who are willing to depend on it in production. AI can lower the cost of producing code, but it does not magically create maintenance capacity or institutional trust.
Second, the scale difference is still huge. PyPI currently lists about 789,821 projects, whereas Julia’s homepage says there are over 12,000 registered packages. That is not a gap you “AI away” quickly. It is the accumulated result of decades of adoption, education, corporate use, and package maintenance.
Third, Python’s ecosystem advantage is not just quantity. It is also path dependence. Many packages exist because millions of users, researchers, companies, and courses already standardized on Python. AI may help Julia developers write more code, but it will also help Python developers write more code. So AI is not a special Julia accelerator; it is a general force multiplier.
Fourth, Julia does not need PyPI-scale package count to be successful. That is the wrong target. Julia’s real comparative advantage is in domains where language design matters more than raw ecosystem breadth: scientific computing, simulation, optimization, HPC, engineering, and research software that suffers from the two-language problem.
So yes: Julia is still overlooked relative to its merits. But the bottleneck is not syntax, benchmarks, or awareness. It is institutional adoption. To me, the path forward seems to be patient ecosystem building in high-value domains, not expecting a general-language takeover. Part of that is making Julia more visible in higher education, where future researchers and engineers form their technical habits.
Disclaimer: Written by me with AI assistance.
What makes Julia unique is not any single feature in isolation, but the intersection of three properties that almost never coexist in one language:
Many languages offer one or two of these. Julia is the only language I know that offers all three at once. That is why I do not see it as merely competing with Python, MATLAB, or Fortran on their own terms. It occupies a distinct, and in my view nearly singular, position in the programming-language landscape.
IMO there are 3 major categories:
those who do not do any programming (this is getting rare these days),
those who use a canned tool like Stata, R, etc
those who implement and debug complicated numerical algorithms, often needing speed, AD, etc
(1) may not have heard about Julia at all, since it is irrelevant for them, like all programming languages. (2) may or may not have heard about it, but has no incentive to explore. The majority of (3) have looked into Julia at some point seriously.
… and that fraction (%?) then is interesting: what percentage a) has stayed so far (and thus been spreading the word, i.e., R_0 > 1) or b) has switched to something else again, and what percentage of b) will be open for a reevaluation?
EDIT: Only that (3) fraction cares for solving the 2 language problem, the others don’t have it.
While this is interesting in the sense that all data is interesting, if I could ask a genie for data on 1–5 things about the Julia ecosystem, for me this question would not make it to the top 20.
The popularity contest part of languages is only interesting until a language community reaches critical mass. Julia is long past that point.
I don’t think it is, in the context it was designed for: a scientific programming language. It is designed for the same purpose as Fortran, Matlab/Octave, R, Num/SciPy, and a couple more niche ones. I think that most people using a language from this list have at least looked at Julia, and a couple other languages.
The key stylized fact about programming language popularity is how long the tails are. C/C++/C#/Java/Python get maybe a 50% share, and then you are into 2%–1%–0.5% territory, which is full of great programming languages with a dedicated community.
I think that understates the issue.
I was not asking about “popularity contest” data in the shallow sense, but about ecosystem dynamics: how many serious evaluators convert into lasting users, how many drop out again, and how many might return once pain points improve.
For Julia, that seems highly relevant. A language community is not just a headcount once it passes some survival threshold; it has an internal structure: novices, intermediate users, advanced users, maintainers, and institutional adopters. The distribution across these groups, and the transition rates between them, strongly affect library quality, mentoring capacity, package maintenance, hiring, and ultimately adoption outside the current core.
So even if Julia is already past “critical mass” in the sense of likely persistence, that does not make these numbers uninteresting. On the contrary: they are exactly the kind of numbers one would want in order to understand whether Julia is merely stable, or actually still compounding.
At present Julia is an almost too powerful programming language.
Kernighan’s old article “Why Pascal is not my favorite language” is an instructive contrast: Pascal’s problem was crippling rigidity for serious reusable programming. Julia’s problem, if anything, is closer to the opposite — it gives you so much expressive power that good interfaces, restraint, and discipline matter a great deal. In other words, Julia fixes Pascal’s “no escape” problem by permitting escape — and then has to spend design effort containing the blast radius.
Julia’s answer to that question is tooling. Eg JET.jl will catch a lot of stuff that a bondage & discipline language like Pascal would enforce at the language level.
This is the right model for transitioning from quick prototyping to production code in a rich, interactive language like Julia.