Well, if we want to consider the programming language Class of 2012, Julia doesn’t look all that bad, if Github stars are your metric:
Tiobe (again, FWIW) tells a similar story, though I note Julia is up a couple more spots since last month.
Well, if we want to consider the programming language Class of 2012, Julia doesn’t look all that bad, if Github stars are your metric:
Tiobe (again, FWIW) tells a similar story, though I note Julia is up a couple more spots since last month.
My super-scientific theory is that we are now seeing saturation for early adopters and the exponential will start as the basic scientific frameworks become a bit more mature and make all the pros of Julia clear to the masses.
I just wanted to add that I was unable to articulate it this clearly, but what you’ve written here is exactly why I use Julia. I just assumed it was the same for most other people too.
If you’re a tinkerer, Julia is the absolute best IMHO. But most people are not tinkerers, and so slower adoption seems a reasonable/expected outcome.
Well, I am a new user and would like to use Julia, but as I pointed out here I need as result “complete” programs, meaning with a UI.
I am an engineer and we serve other engineers with our sensors. And sensors need to be read out their data has to be analyzed in a scientific way. So Julia as a scientific programming language should be our choice. But I cannot deliver program code in form of a script to a customer. Human work time is in laboratories an expensive good, therefore a well-thought UI software is crucial. The more time people can save by using your software the more attractive your product becomes. Here I really see a big market for Julia. For Python you find everything you need but you need a lot of time to get it fast enough e.g. to do some neuronal net things on a barebone PC as they are meanwhile popular to save hardware costs.
So what I can say from my perspective, if there is a way to compile a Julia module under Windows to a DLL and then use this DLL for the GUI framework one needs or is used to, then Julia makes sense.
As a newbie, what is “juliac”? Could that solve my problem and if so, where can i find a step by step instruction on how to compile my Julia module to a DLL with it?
It’s the more-or-less unreleased CLI compiler. You can read about it here and here.
As noted, it is a first step toward addressing your problem, but there remains work to be done.
As we discussed, you can do this today with PackageCompiler; it just probably won’t be small. I would hazard to guess that, if you can get it working that way, the forthcoming compiler improvements will continue to make the process and results better.
What happened in 2019?
I’m thinking that the bump on the graph is related to Julia 1.0 being released.
Julia’s comparables are usually Python, MATLAB, R and FORTRAN. Strictly speaking Python is a general-purpose programming language, not limited to scientific computing. Don’t forget that MATLAB is closed source commercial software, there is no comparison.
NumPy provides functionality that is built-in to Julia, and, Numpy provides matrices in nested lists [[1,2,3],[4,5,6]]
, and Julia’s matrices are matrices.
You’re saying that C++ and Python combine to replace Julia, not Python alone.
Will Numba’s direct @njit
just load directly in front of the function definition? You need to slice the function into very small parts that can be used with numba, and @njit is very limited in its applicability.
As an engineer, I don’t like or even hate 0-indexed based programming languages, which is why I use Julia.
… but they should not be. A lot of Julia users don’t even have a Github account, you don’t need it unless you want to report issues, make PRs, or host your packages there.
In the long run, indices like TIOBE may be more meaningful, but they are to noise for the purposes of tracking short time horizons. Most of the topics inspired by movements in these indices are just discussing random noise.
Julia is a niche language, as opposed to being a general programing language. Its primary focus remains providing a smooth path from fast prototypes to mature optimized codebases in numerical computation. People are using it for a lot of other purposes, but that happens because they know Julia already, or their application’s core computation is in Julia, and they need to tack on a GUI or something.
Will julia-compile make Julia even more useful? Sure it will, like all other developments. But it is important not to miss the fact that causality runs in the other direction too: these great developments are happening because Julia already has a large base of contributors, and is capable of drawing in funding for a lot of work. Effectively, julia-compile is also a consequence of Julia’s increasing adoption.
The relevant question for computer languages is not relative popularity, but whether they can build a self-sustaining model for the long run. Julia has cleared that bar a while ago.
My two cents: If juliac
becomes mature enough to easily produce Python wheels or APT/RPM packages without users ever realizing Julia is under the hood, it will be a big boost for Julia. When I use e.g. pandoc or ollama on the command line in Linux, I don’t care about the fact that they’re written in Haskell and Go.
As for the perennial discussions about language popularity, I haven’t found a more popular alternative to Juila which combines REPL interactivity with high performance. The only other choice in this genre seems to be Common Lisp, which is less popular (at least in scientific computing) and something I haven’t tried.
Note that while you typically want a programming language to see widespread adoption, you don’t want too many users, too soon. Otherwise you’ll pass the “threshold of immortality” too quickly, meaning your ability to continue innovating in the language design space will suffer, since you’ll have to prioritize catering to the needs of the existing users (especially when these are huge corporations). It takes a lot of time and going back to the whiteboard to get a programming language right. The last couple Julia releases came with a wide array of very significant fixes, new features, and QoL improvements. Development pace seems to be at its highest, there’s more and more funded positions for people to work on the language, the community is healthily growing (e.g., increase of local communities), and there’s more active contributors than ever.
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.
IMO, there is nothing wrong in comparing between julia and rust, since both are general purpose languages, just their ecosystems have been focused on different domains so far, but this can change in the future. As for the question what julia has, which some_other_language does not have, the answer imo is combination of speed of development and high performance. Rust for example allows to produce fast code, but many people complain about difficulty to learn the language, then read and write the code in it. Python, like julia, offers easy learning curve and fast development, but only as long as you don’t care about performance, or high performance backend already exists for your task. When you cross this boundary, making many things done with julia becomes much easier than with python. Juliac could become a big deal in julia ecosystem, if it wiould allow for example to bring julia to programming embedded hardware, where micropython shines, but people still need to switch to C when they need high performance. I recently got involved into microcontroller programming and I already miss julia, although python+C sort of work, I feel that this is not optimal approach and learning rust for now.
This is common conceit, especially since Winestock’s article, but frankly, (Common) Lisp is not that powerful if you want performance. Your typical Lisp compiler will address a couple of heuristics, but will never optimize code the way Julia does, simply because it cannot if you want to keep your code generic (aggressive optimizing compilers exist, but then you are basically coding in C with a bunch of parentheses).
Another perspective is that Julia is a Lisp which figured this out, cleverly disguised in M-expressions (multimethods and macros give it away though).
As I wrote, I cannot. I researched a lot, also used AI search engines but cannot find a step by step instruction how to compile a Julia module to a DLL. And all that I found failed. Also for juliac I could not yet find a step by step instruction.
Back to the topic:
I notice that a lot of Julia announcements and docs assume expert users. If you want to be more attractive for new users like me, explain the things properly. For example explain users what a “precompilation” is, why, when and that is it necessary. For most of you that is a basic but for an average guy like me coming from C++ it is not.
And of course you must give users step by step instructions. This way users can give your feedback at what step they failed and how.
Also in Julia’s official YouTube channel I miss videos for new users. But how will you get new users when the YouTube channel only feature highly technical talks from Julia conferences?
As you compared with Rust. I found a lot of videos explaining me things step by step and that’s why I was able to try out Rust. For now I stay with C++ but once Rust is beneficial for a project I can make the change.
Rust is meanwhile so big that they don’t need to use the official YouTube channel. Julia is not yet as this state. There was once a channel called Doggo dot jl. To be honest, most of what I know about Julia is from that channel. I tried to find infos given there in other resources but failed. Just my advice: if there is funding, pay a person like Doggo dot jl to produce videos to teach people.
I came to Julia because of its scientific features and approach. I really would use it for my projects but the hurdles are very high as a new user how things are done. I mean a proper YouTube video on how to use Julia in practice would work: Go to an average research lab of your choice and explain how the workers there (the company running the lab) can benefit from Julia, how different software for different needs could be created with Julia and the like.
As it is, it seems to me that Julia is mainly used at universities, therefore there is no optimal awareness of the needs once the students went to the industry.
I am not sure how popular this website is, but I like it and Julia ought to be represented here: https://www.w3schools.com
That’s really the crux of the matter… there really isn’t any funding, so the availability of beginner-friendly materials are based on volunteer efforts or what people can do “on the side” of their otherwise funded jobs. These things accumulate over time, though, so that situation is not hopeless. It would absolutely be great if there was room for more concerted efforts to fund people specifically to produce such material.
At least one famous counterpoint is ASML. You might find their JuliaCon talk intereresting: https://www.youtube.com/watch?v=uYhQHMtHJrU (as well as their talks in previous years).
I realize that doesn’t address your particular problems, which are definitely legitimate concerns.
Maybe I give too much importance to the Julia-lang blog, but I find it surprising that there is no blog post either about Julia on Colab or about juliac. I am glad that the Julia-lang blog is publishing more and more content, even from third parties, but I still think there is room for improvement.
OK, then I should out myself: I am part of the FreeCAD association. We have funding channels and use the money we get for different purposes. Some to pay development, some to fix bugs but always some to make PR, people making blog posts, videos, or even those who improve our Wiki. The latter turned out to be very successful because in a time at which people use AI search engines, you always get a solution as the bots are aware of the Wiki.
For Julia there is no Wiki where for example people like me could post their info. For example once I started with FreeCAD, there were no Windows developers. I went through the issues and whenever I solved a problem, I documented for others how to do things. And by time we got more and more developers on Windows, because you can now just strictly follow all these steps and will get a running FreeCAD and can start coding.
Or we paid persons to document what you can do with FEM. And now, 2 years later we have a nice and active community using and improving that part of FreeCAD. I often say “an undocumented feature is an unused feature” so looking back at my work for FreeCAD, I spent most of my time in documenting rather than actually coding.
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.