The release of Julia 2.0 could spark additional interest in the Julia community and thus, provide a unique opportunity to promote Julia.
What steps should the Julia community take from now until the release of Julia 2.0 to bring Julia to the next level of popularity?
From what I understand, tagging a breaking 2.0 release is not among the communityās short-term priorities. Stability of the API has been enforced since Julia 1.0, and it is something many people consider important.
Besides, a lot of improvements to the language can be implemented in a non-breaking way, as the recent 1.9 and upcoming 1.10 demonstrate.
In my opinion path to popularity lies through academia. Best way is to provide internships to students and collaborate with industry for that. help professors to design their computational courses in Julia. 
One of the best consequences of going to 1.10 is that the false impression that 2.0 is around the corner will be somewhat tempered.
Releasing 2.0 now would only be negative, the actual userbase wants Julia do keep compatibility so (i) their codes will not break for basic reasons (like a Base method changing name) and (ii) they want to be able to use the argument that Julia is stable and backwards compatible for the last X years and there is nothing in the horizon to change this anytime soon.
I have chosen Julia 2.0 as a possible milestone because it may arouse extra interest. But, if Julia 2.0 is still far off in the future, the release that may spark the most interest is the next LTS release. Whether itās Julia 2.0, the next LTS release or Julia 1.10, what Iām most interested in knowing is what steps the Julia community should take to bring Julia to the next level of popularity.
Iāve suggested in a previous post, to make an essay ācompetitionā about this same topic: Julia FTW (for-the-win). Everyone gets a chance to write an up-to 1000 word essay and the community/JuliaCon chooses a few winners (perhaps read out loud in a session during Juliacon). I think the up-to-1000 word essay format is a good one to promote thoughtful reflection and avoid branching off into a multitude of little arguments.
This blog post is pretty similar IMO: Why We Use Julia, 10 Years Later
Perhaps if marketing is important we should forget SymVer and call the next version āJulia 2024ā 
Julia could follow SemVer, and name the LTS version with the year it is released, like Rust does.
I suppose 1.9 could be the next Julia LTS, and if it very to be supported for thee years, then I donāt seed it as bad to start looking into releasing Julia 2.0. Most code should be compatible, and tested, with both.
nope, given how (not very) popular Julia is right now, 2.0 will basically kill the language adoption, any potential julia-curious decision makers would think āmaybe I will look at Julia again in 10 yearsā
the vibe seems to be that Julia 2.0 is as likely as Python 4.0 ā hopefully never
As I believe Iāve said before. For julia to decide a 2.0 release there has to be a very compelling reason to make break changes, and at least in the mid term future thereās still a lot that can be done to improve the language without braking changes, from tooling support, to GC, to threading. All of these can become better wihout breaking code.
Iām sorry I mentioned Julia 2.0 because it sidetracked the conversation. I should have focused on the upcoming LTS instead.
If Julia 1.10 eventually becomes LTS, is there any chance that it will also become Julia 2023? How could the Julia community promote Julia more effectively when Julia 1.10 is released?
Not sure what Julia 2023 means.
You can see what issues are tagged as breaking in the Julia repository on GitHub. Right now none of them are particularly good candidates for a strong 2.0 feature. They are nice to haves, things the community has learned over time, but not very important in the grand scheme of things.
The Julia project has learned quite a lot from previous languages that make these changes, the most obvious example being Python. If and when such a feature comes around (the most obvious change might be some sort of changes necessary for trait based dispatch) this process would take years.
As an example many core devs very much want to remove some Standard Libraries from the language (SparseArrays.jl, DelimitedFiles, Statistics, etc). But this wonāt happen unless there is some massive feature which justifies the engineering effort to ensure a perfectly smooth transition.
Agreed, I see people occasionally having issues learning Julia because they were looking at posts with v0.7 code or unstable internal code and hadnāt realized it would not work across v1. Imagine what happens if v2 rolls around and the much bigger amount of v1 code posts you can reach on Google becomes useless all at once. Python 3 only made it because it was adopted by important third party packages, and people still werenāt happy about the major revision that didnāt fix most of the big problems. Julia has a lot of problems that can be solved in v1, itās probably wiser to exhaust those before considering what problems actually need to be solved by a v2.
Julia already has a versioning system in place (semantic versioning), which informs users about compatibility and minor / patch releases. I donāt think adding a second layer of year-based version numbers would be useful, and it might generate a lot of confusion.
In addition, as soon as we enter 2024, anyone using Julia 2023 would probably feel like itās outdated. On the other hand, there is no particular reason to feel like Julia 1.9 is outdated until the next version comes out. The same way people donāt need to call it Python 2023 to feel like Python 3.11 is modern.
I understand the idea that we could use a specific release to boost communication. Personally, I think 1.9 is the best thing since sliced bread, and Iāve been selling it to my colleagues as the turning point where Julia startup finally ceases to be a pain in the butt.
What did I observe? Those who were already using Julia enjoyed the speed boost, but those who were using Python were not convinced to transition.
Widening adoption is a long term goal, which the folks here have been working on for a while. And the most effective way to convert someone to Julia is to solve a coding problem for them, or better yet, with them. So in my view, the community should keep doing what it does best, and what it is already doing:
If you ask me, weāre on the right track already.
Has the Julia community effectively communicated that Julia 1.9 is a significant improvement in ergonomics? Would it have been better communicated with a blog entry about this on Julia-langās website? From a marketing standpoint, would it have been clearer that Julia 1.9 is such a significant improvement if it had been LTS?
Besides improving Julia and its ecosystem, is there a way to speed up the adoption of Julia? Could short videos on new features like VSCode does help?
I get the feeling that most of Juliaās material is heavily influenced by academia (extensive blog posts, lengthy video lectures), and may not be the best material for promoting language. I imagine a few short videos on cool simulation might help more.
julia-vscode/LanguageServer.jl
Before the vscode extension has a better bug minimal state, doing too much marketing would disappoint a lot of people.
Check out the blog post Julia 1.9 Highlights 
I donāt think the average user cares about the LTS, especially in academia. We update to the latest stable version whenever it comes out and weāre quite happy that way. Industrial applications are more likely to require long term stability, but I canāt speak for this world.
I do know, however, that there are codes in prod at big companies which donāt run on LTS. That it is made much safer by Juliaās built-in reproducibility (give me a Manifest.toml and I can reproduce your results years later).
To sum up, Iām not sure LTS matters as much as you believe. Itās important to have one, sure enough, but updating it is not urgent by any stretch.
It sure could be useful, and youāre welcome to try it! Thereās already tons of material on the Julia YouTube channel or other channels like doggo dot jl, but more can never hurt. You will definitely get better results if you start the momentum yourself, and people might join in!
