Again, my experience is different. Julia devs are wise enough to recognize that it is impossible to design a complex language without some parts that one, in retrospect, would do differently, and have learned to live with the mistakes (iterable Reals, I am looking at you ). Discussing language design in a polite and detached manner is generally not controversial.
That said, the key question is always practical: what should we do about the mistakes, especially if a change would be breaking? On this, opinions can differ, especially given how difficult it is to ensure that the new design that replaces the old mistake does not turn out to be a mistake in itself.
I am hoping that as standard libraries get moved out from the language proper, we get a chance to reorganize some APIs and at least fix some mistakes.
Putting Julia (only) under umbrellas that sound scientific, numerical, HPC⌠can act as a repellent for the rest of the developers (and industries) that are not specifically interested in those areas.
I think putting Julia under different umbrellas that are not explicitly focused on high-performance/scientific/technical could attract different flavors of developers and aid the development of the Julia package ecosystem beyond niche areas.
Important note: This doesnât imply removing Julia from NumFocus - such a thing is not at all crossing my mind when writing this.
But if we discuss, for example, NumFocus vs. Free Software Foundation and keep only one condition is applied, then I would think that Free Software Foundation is more appropriate.
On Julia homepage, the language is also presented as being general:
Now, I understand (and it is understandable) that with most of the Julia Language developers rooted in scientific/numerical field, the language will taste in a certain way: I do not expect the existing developers to do anything different.
However, signaling to the outside world that Julia is not only fit for scientific/numerical computing can make more developers at least willing to try the language. I think it is conceivable that some developers without links to scientific/numerical computing might fall in love with the language and start contributing (both to the language and the package/community ecosystem).
Even if we only discuss the subject of doing justice to the language, trying to reach outside scientific/numerical computing boundaries is the right thing.
Agreed. From a marketing point of view, NumFocus seems more suitable for SciML and JuMP than for Julia.
It may not be possible now, but Julia becoming a foundation like Python or R would be seen as a successful milestone for many. For example, Pytorch becoming a foundation reinforces the idea that Pytorch is the de facto ML framework in the Python world.
Julia Con should also send this message by selecting more non-specifically scientific talks.
I think you may be overestimating the effect of these âumbrellasâ â I would assume that the majority of programmers who consider Julia just evaluate the language on its own merits.
And there is no denying the fact that the comparative advantage of Julia is scientific programming. This does not mean that it isnât a general language (it is), but at the same time few other languages deliver the mix of code reuse (multiple dispatch), interactive development (REPL), and speed that Julia does.
Why would we do this work? Have you been told that thereâs some guaranteed funding that weâd get if we did the change? Are you willing to do the paperwork? If thereâs no money and nobody cares to actually be the one doing the paper work, then itâs not worth anybodyâs time.
Letâs assume for a moment that umbrellas are important for signaling (I donât think so, but it is an interesting thought experiment).
Then what your suggestion ignores is the opportunity cost: we would necessarily weaken the signal that Julia is the right choice for scientific programming. One cannot signal everything at the same time. So we would lose some of the audience that is actually the perfect match for Julia.
And the other opportunity cost is that someone would have to do it. It would be quite a bit of paperwork. Do we think itâs worth more than say 50 hours of docs work or a new grant? I donât think so, and thus I wouldnât do this myself.
I would assume that the majority of programmers who consider Julia just evaluate the language on its own merits.
That may be the case (e.g. Rust has been voted the most loved language for many years in a row). Commercial choices, which in turn support and promote the language, are driven by other factors.
People talk about niches as if they were a bad thing. Theyâre not! Embrace the niche!
The claims that Julia is a âgeneral purpose languageâ seem somewhat tongue-in-cheek. Sure, itâs more general-purpose than Matlab, Fortran, or R (and thereâs nothing wrong with advertising that fact), but itâs much less general-purpose than Python or C++, and thatâs a good thing. Julia is very much a language designed for scientific computation, and quite honestly, I think it is best served by continuing to be the best language it can be in that domain.
Given how young the language is, it seems to me that its level of popularity is growing quite healthily. I donât think the community (or the core developers) need to do anything in particular to move Julia to the ânext levelâ of popularity, except: carry on. Sure, the tooling (linters/debuggers) needs to improve. Thereâs still âcorrectness bugsâ in Zygote etc. that need to be addressed. But remember that Juliaâs 1.0 release was in 2018. If we want to compare to the Python ecosystem (1.0 release in 1994), weâre in 1999 right now. Of course, Julia is standing on the shoulders of that development, but the growth of its ecosystem is much stronger than what I remember Python before 2015 or so being like. Give it time. Things will fall into place.
What really pushes Julia forward, IMO, are the strong community (like this Discourse), JuliaCon and the steady stream of Julia talks showing up on YouTube, and more than anything, just people using Julia. Nothing drives adoption more than results, that is, people demonstrating to their colleagues how Julia beats the pants off the existing Python/C++/Fortran/Matlab/R solutions in their field.
From my perspective, since Julia is already great at scientific computing and there is a steady and quite sustainable path to even further improvement, I think expanding the general-purposeness of the language would mainly be to push things like better tooling for deployment, interoperability, and the web, removing barriers to adopting it in various production settings. If those barriers are removed, it becomes even easier to reap the benefits of a single language for prototyping/research and production.
Would a better metric of Julia popularity be the number of universities teaching Julia and/or the number of papers/theses using Julia than the Tiobe index?
I didnât see every reply in this thread, but did anyone mention that Julia recently reached the top 20 in TIOBE? With all the flaws, problems, possible improvements etc mentioned here, this is an amazing achievement! Compare this to Scala, a languaget that has been around about 8 years longer than Julia. While it shares the same background - coming from the academic world, Scala from the get go was an integral part of one of the largest software ecosystems in the world - Java. Scala is in fact a âbetterâ Java-- easier to learn and better in 50 different ways. One of the most popular data engineering frameworks out there (Spark) which has a huge and successful corporation behind it (Databricks) and has very heavy adoption in both the corporate and startup world is written in Scala and supports Scala as a first class language. All this did absolutely nothing to make Scala more popular. In fact, Scala popularity continues to sink, as Databricks and Spark continue to prosper.
As someone who has learned more than a couple of dozen languages in the course of my career, I can say what is great about Julia is that it combines a coherent academic-based vision (like Scala) with a grounded programmer pragmatism (unlike Scala). That makes it relatively easy to learn, efficient in solving complex problems, and most importantly fun to use!
Scala started out as an academic exercise in developing a general purpose language and then its developers began looking around for application spaces. By contrast Julia was initially created to address an important niche in software development (scientific computing). This niche borders on a much larger niche in software development (data science/ML) which allows Julia to grow even more. Python was more similar to Scala in its origins, and for many, many years wandered in the wilderness. Then for various reasons Google brought van Rossum on board and the rest is history. Its success and popularity are more luck than any concerted effort to make it popular. Many of the better things people mention about Python (more frameworks, better documentation) is not why it succeeded but the result of its success! R and Matlab are more like Julia - programming languages built for a niche. They have been around much longer (R~20 years with roots in S going back even further, Matlab~30 years) so of course they are more popular. My guess: over time Julia will eat their lunch. I am willing to venture that as Julia becomes more and more popular, someone will create a JuliaStudio, a company will be born, and R will begin to fade away.
All this is to say I agree with @Tamas_Papp : the key to Juliaâs continued growth and success and reaching the next level (i.e. permanently in the Tiobe top 20 and scraping at the Tiobe top 10) is to continue to invest in its development and ecosystem, not worry about promotion!
Exactly. It seems to me that things are actually going fine.
We just need to keep that moving. Julia is almost entirely built on pull requests to base and packages. Code, docs whatever: PRs are where things actually happen and real decisions and changes are made. Not in these threads.
So improving Julia is very closely correlated with how many PRs are written and merged in base and the ecosystem.
Fix correctness in base and packages, improve docs, add missing functionality, write cool new things. Isnât that what needs to happen? Isnât it that simple?
My answer to the question of this thread is, if youâre not already, go write a PR or help someone else write one.
Me here. I usually start by reading the docs. Almost always useless, since they are incomplete.
Juliaâs docs are better than the average, and still not sufficient for beginners.
Yep. I already did minutes ago, and plan to do so as well in the future. By the way:
Is my VSCode broken, or does Julia simply not show red squiggles to show syntax errors?
). Discussing language design in a polite and detached manner is generally not controversial.