# What steps should the Julia community take to bring Julia to the next level of popularity?

**URL:** <https://discourse.julialang.org/t/what-steps-should-the-julia-community-take-to-bring-julia-to-the-next-level-of-popularity/101389>\
**Category:** Community\
**Created:** [July 9, 2023, 9:59am UTC](https://discourse.julialang.org/t/what-steps-should-the-julia-community-take-to-bring-julia-to-the-next-level-of-popularity/101389 "2023-07-09T09:59:36Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![aplavin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aplavin/32/222056_2.png) [@aplavin](https://discourse.julialang.org/u/aplavin)\
**Post date:** [July 10, 2023, 12:00pm UTC](https://discourse.julialang.org/t/what-steps-should-the-julia-community-take-to-bring-julia-to-the-next-level-of-popularity/101389/21 "2023-07-10T12:00:12Z")

</div>

> [@gdalle](#):
>
> 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).

How reproducibility through Manifest is related to LTS/nonLTS? Manifests are reproducible only within a single Julia version anyway.

---

<div class="post-metadata">

**Author:** ![gdalle](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gdalle/32/27854_2.png) [@gdalle](https://discourse.julialang.org/u/gdalle)\
**Post date:** [July 10, 2023, 12:03pm UTC](https://discourse.julialang.org/t/what-steps-should-the-julia-community-take-to-bring-julia-to-the-next-level-of-popularity/101389/22 "2023-07-10T12:03:36Z")

</div>

I mentioned it because LTS is useful for people who care about long-term code maintenance, but in many cases it may not be needed. Of course you’re right, a `Manifest.toml` won’t save you if there’s a bug in your non-LTS Julia version.  
In any case, I would wager that for industrial applications, the package ecosystem is a much more brittle aspect than the actual language itself. In other words, I would trust a non-LTS Julia version way more than I trust any individual package.

---

<div class="post-metadata">

**Author:** ![mihalybaci](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mihalybaci/32/13528_2.png) [@mihalybaci](https://discourse.julialang.org/u/mihalybaci)\
**Post date:** [July 10, 2023, 2:52pm UTC](https://discourse.julialang.org/t/what-steps-should-the-julia-community-take-to-bring-julia-to-the-next-level-of-popularity/101389/23 "2023-07-10T14:52:32Z")

</div>

I’m definitely on the side of delaying Julia 2.0 as long as possible and haven’t really seen many issues worthy of issuing a breaking release. However, in light of the new [threading PSA](https://discourse.julialang.org/t/psa-thread-local-state-is-no-longer-recommended-common-misconceptions-about-threadid-and-nthreads/101274/40), is updating/deprecating the threading foot-guns a strong reason to push for 2.0? Or can any relevant problems be solved by non-breaking releases (or just encouraging better code)?

---

<div class="post-metadata">

**Author:** ![gbaraldi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gbaraldi/32/22101_2.png) [@gbaraldi](https://discourse.julialang.org/u/gbaraldi)\
**Post date:** [July 10, 2023, 2:53pm UTC](https://discourse.julialang.org/t/what-steps-should-the-julia-community-take-to-bring-julia-to-the-next-level-of-popularity/101389/24 "2023-07-10T14:53:48Z")

</div>

I believe we can address those issues with non breaking changes, by basically offering solutions that work better than what’s available right now.

---

<div class="post-metadata">

**Author:** ![lmiq](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lmiq/32/18314_2.png) [@lmiq](https://discourse.julialang.org/u/lmiq)\
**Post date:** [July 10, 2023, 3:34pm UTC](https://discourse.julialang.org/t/what-steps-should-the-julia-community-take-to-bring-julia-to-the-next-level-of-popularity/101389/25 "2023-07-10T15:34:33Z")

</div>

The issue there is only that `@threads`, `nthreads()` and `threadid()` seem part of the same package of multi-threading features, such that it is too tempting to use `threadid()` to index buffers in a `@threads`-ed loop. That can be solved simply by creating a new macro, lets say `@parallel`, or whatever, suggest proper patterns for its use in the documentation, and let `@threads` and companion be slowly forgotten in some low-level development part of the docs. The name `@threads` is bad, anyway.

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [July 10, 2023, 5:19pm UTC](https://discourse.julialang.org/t/what-steps-should-the-julia-community-take-to-bring-julia-to-the-next-level-of-popularity/101389/26 "2023-07-10T17:19:45Z")

</div>

Bringing Julia to the next level of popularity requires to provide an IDE with a lot less issues…  
I suggest to set up a work group to discuss (e.g. on Zoom) how this could be achieved.

---

<div class="post-metadata">

**Author:** ![JackaChou](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jackachou/32/35269_2.png) [@JackaChou](https://discourse.julialang.org/u/JackaChou)\
**Post date:** [July 10, 2023, 11:40pm UTC](https://discourse.julialang.org/t/what-steps-should-the-julia-community-take-to-bring-julia-to-the-next-level-of-popularity/101389/27 "2023-07-10T23:40:37Z")

</div>

If a IDE like spyter also including Pluto and Jupyter, that will be wonderful.

---

<div class="post-metadata">

**Author:** ![gdalle](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gdalle/32/27854_2.png) [@gdalle](https://discourse.julialang.org/u/gdalle)\
**Post date:** [July 11, 2023, 8:07am UTC](https://discourse.julialang.org/t/what-steps-should-the-julia-community-take-to-bring-julia-to-the-next-level-of-popularity/101389/28 "2023-07-11T08:07:47Z")

</div>

You can use Jupyter within VSCode already. As for Pluto, it may take some time

---

<div class="post-metadata">

**Author:** ![xiaoxi](https://avatars.discourse-cdn.com/v4/letter/x/a9adbd/32.png) [@xiaoxi](https://discourse.julialang.org/u/xiaoxi)\
**Post date:** [July 11, 2023, 8:48am UTC](https://discourse.julialang.org/t/what-steps-should-the-julia-community-take-to-bring-julia-to-the-next-level-of-popularity/101389/29 "2023-07-11T08:48:26Z")

</div>

> [@gdalle](#):
>
> Check out the blog post [Julia 1.9 Highlights](https://julialang.org/blog/2023/04/julia-1.9-highlights/)

As someone with no CS background and not very familiar with Julia, I find it difficult to understand the highlights of the new Julia releases. They are full of jargon and focus more on the mechanics of Julia than the syntax of the language itself.

> [@gdalle](#):
>
> 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.

I think a second blog post with less jargon, more accessible to a wider audience, and focused on how new versions improve daily workflows as you have done could very helpful.

> [@ufechner7](#):
>
> Bringing Julia to the next level of popularity requires to provide an IDE with a lot less issues…

Is a good language server and better IDE support currently one of the main pain points in Julia? Would it help to have a mechanism similar to what Rust’s language server has to raise money?

> **[rust-analyzer Financial Report #4](https://ferrous-systems.com/blog/rust-analyzer-financial-report-4/)**
>
> Financial Report #4
> 
> 
> This is the fourth financial status report of the rust-analyzer project Ferrous Systems fund.
> 
> 
> This one is loooong overdue, apologies for that! We will be posting these reports yearly from now on.
> 
> Since the last report,...

---

<div class="post-metadata">

**Author:** ![greatpet](https://avatars.discourse-cdn.com/v4/letter/g/e495f1/32.png) [@greatpet](https://discourse.julialang.org/u/greatpet)\
**Post date:** [July 11, 2023, 9:52am UTC](https://discourse.julialang.org/t/what-steps-should-the-julia-community-take-to-bring-julia-to-the-next-level-of-popularity/101389/30 "2023-07-11T09:52:10Z")

</div>

> [@xiaoxi](#):
>
> They are full of jargon and focus more on the mechanics of Julia than the syntax of the language itself.

I think the syntax has largely settled down. Recent releases of Julia mainly improves other things like the compiler, though occasionally some light syntax sugars are added.

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [July 11, 2023, 12:41pm UTC](https://discourse.julialang.org/t/what-steps-should-the-julia-community-take-to-bring-julia-to-the-next-level-of-popularity/101389/31 "2023-07-11T12:41:27Z")

</div>

> [@xiaoxi](#):
>
> Would it help to have a mechanism similar to what Rust’t’s language server has to raise money?
> 
> [rust-analyzer Financial Report #4 - Ferrous Systems](https://ferrous-systems.com/blog/rust-analyzer-financial-report-4/)

Sounds very interesting!

Raising money is one thing, but then we would also need to find a developer and supervise him or her…

---

<div class="post-metadata">

**Author:** ![Jose\_Diaz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jose_diaz/32/43750_2.png) [@Jose\_Diaz](https://discourse.julialang.org/u/Jose_Diaz)\
**Post date:** [July 11, 2023, 1:49pm UTC](https://discourse.julialang.org/t/what-steps-should-the-julia-community-take-to-bring-julia-to-the-next-level-of-popularity/101389/32 "2023-07-11T13:49:46Z")

</div>

From the industry point of view:

- Compiler-wise: Static Compialtion, cross compilation (apparently being a priority for the compiler team, so that’s great news)
- Package-wise: Better ONNX support and other file formats.

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [July 11, 2023, 2:32pm UTC](https://discourse.julialang.org/t/what-steps-should-the-julia-community-take-to-bring-julia-to-the-next-level-of-popularity/101389/33 "2023-07-11T14:32:41Z")

</div>

> [@Jose\_Diaz](#):
>
> and other file formats

What do you mean with other file formats?

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [July 11, 2023, 5:26pm UTC](https://discourse.julialang.org/t/what-steps-should-the-julia-community-take-to-bring-julia-to-the-next-level-of-popularity/101389/34 "2023-07-11T17:26:25Z")

</div>

On your two points you think are lacking for industry adoption:

> - Compiler-wise: Static Compilation, cross compilation […]
> - Package-wise: Better ONNX support and other file formats.

Note, you can _ **already** _ compile to static binaries for Linux, Windows and macOS, with PackageCompiler.jl, and **such binary executables are already used in productions by companies**. [People already cross-compile, at least for Raspberry Pi? I’m not sure how well it’s supported.] If you mean static tiny executables, then there are more experimental packages which achieve that for Linux, but they only support a rather limited subset of Julia.

[“Package-wise”, e.g. ONNX, is in the hands of the ecosystem, there’s nothing _Julia_ can do about it, or rather IMHO should do about it. Do you disagree?]

Regarding compilation, **you can only choose two of these three: generic, fast (in all cases) and tiny binaries** (and that trilemma applies not just to Julia but also to all languages as powerful, e.g. Lisp). You can have precompiled fast code (already, e.g. packages in 1.9), but using code, e.g. from the REPL, _in arbitrary ways_, i.e. generic code, isn’t possible without a compiler, if you want the code to be fast. Why you need the heavy dependency LLVM, or equivalent, meaning a (backend of a) compiler. Julia is more powerful than e.g. C, C++ and Rust, in this way and getting rid of the compiler, at runtime, limits its power. You could still have precompiled fast packages, as you do already since 1.9, but some code would need to be slow, i.e. interpreted (already possible with Julia, people may not be aware of that). You could still support all code (and have e.g. the GC), it’s just that the generic part of Julia, or any language, rules out precompiling, since it’s for infinitely many types, some (actually vast majority) not yet invented.

I actually had a thought about this (and other things) that kept me from sleeping until 7 am. I have a plan for Julia 2.0, 3.0, and maybe even 4.0… and will discuss it separately later. I think we want to go to minimally breaking Julia 2.0, but my idea for 3.0 is “maximally breaking”, to see where that leads (e.g. no heavy dependencies, such as LLVM and excise ALL of the standard library, or as much as I can, though you could add it back through packages) and it could lead to tiny executables without many limitations… only sometimes slower (similar limitations as Python with its packages written in fast C), as explained above.

It seems decided that 1.10, not 1.9, will be the next LTS. My idea is that all code that would work in 3.0 will work in 2.0, and all code that works in 2.0 will work in 1.x, and code should be tested one latest Julia (3.0) and 1.10 LTS. And hopefully all 1.x code will be supportable in 2.0 with trivial updates, hopefully just by adding Julia1.jl to the environment.

> 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)

Basic reasons like changing a name (in `Base`, or anywhere really, in packages too), in effect means drop the old name, and add the new name. It can be done in a trivially non-breaking way by just adding the new name as a synonym, e.g. people ask for that to make the language more consistent. Some 2.0 proposals are that basic, and the downside is then there are the new and old way, some mental clutter, I suppose the docs should just deemphasize the old way (rather that drop it from the docs). Dropping the old name could be deferred indefinitely, and arguable should just not be done according to Rick Hickey. Some proposed 2.0 are less trivial, i.e. with semantic changes. E.g. I propose Integer ^ Integer should result in Float64 (thus type-stable working for all numbers), i.e. not resulting in an Integer, since that’s in general not possible (for negative powers) and is a footgun of Julia (likely will overflow).

> [@xiaoxi](#):
>
> How could the Julia community promote Julia more effectively when Julia 1.10 is released?

I don’t a have a good answer for 1.10, or 1.9, but note the answer is the same. Each 1.x release is non-breaking, i.e. you don’t need to wait for 1.10 to promote. Nor be that worried what’s exactly in the latest release. It’s always more of the same goodness, plus e.g. much improved speed (of startup, the so-called time-to-first-X, TTFT; used to be called time-to-first-plot, TTFP, the more specific limitation).

It’s understandable people are skeptical of 2.0, because according to semver, it means breaking changes. It the past some “technically breaking changes” have been allowed, but anything more visible is deferred to 2.0. I have some in mind that are minimally breaking, an improvement still, more likely to result in correct results, as with my power (^) example above, so in by some definition not breaking at all.

---

<div class="post-metadata">

**Author:** ![adienes](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/adienes/32/37459_2.png) [@adienes](https://discourse.julialang.org/u/adienes)\
**Post date:** [July 11, 2023, 6:18pm UTC](https://discourse.julialang.org/t/what-steps-should-the-julia-community-take-to-bring-julia-to-the-next-level-of-popularity/101389/35 "2023-07-11T18:18:30Z")

</div>

> [@ufechner7](#):
>
> What do you mean with other file formats?

parquet, arrow. there is support but I still regularly run into issues

---

<div class="post-metadata">

**Author:** ![mthelm85](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mthelm85/32/224164_2.png) [@mthelm85](https://discourse.julialang.org/u/mthelm85)\
**Post date:** [July 11, 2023, 6:32pm UTC](https://discourse.julialang.org/t/what-steps-should-the-julia-community-take-to-bring-julia-to-the-next-level-of-popularity/101389/36 "2023-07-11T18:32:08Z")

</div>

> In my opinion path to popularity lies through academia.

I strongly disagree. In the USA, only about 2% of the population aged 25 and older has a doctorate degree. However, I remember as a new Julia user coming to the community back in 2018 (mainly here on Discourse) being a bit intimidated as I am not an academic and I don’t have a doctorate degree. I got the impression that the community largely consisted of scientists/academics and the like, and I felt like I didn’t fit in (especially considering that the community I was most involved in before was the JavaScript community). I suspect I’m not the only non-academic to dip a toe into the Julia pool and feel that same vibe.

I think the community should be thinking about ways to do the exact opposite - expand the user base _outside_ of academia and ensure the community feels like a place where anyone (regardless of job or education level) can fit in, learn, and achieve great things with this wonderful language.

I took a quick look at [this 2021 Python Developers Survey](https://lp.jetbrains.com/python-developers-survey-2021/) and there are a few points that I find interesting:

- A substantial proportion (29%) of respondents are using Python just for personal/educational/side projects
- Most users are using Python for data analysis and web development
- Two-thirds of respondents said they do not consider themselves a Data Scientist

While this is certainly speculation on my part, I am willing to bet that the vast majority of Python users are outside of academia (if anyone can find data on that, please post).

---

<div class="post-metadata">

**Author:** ![cpfiffer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cpfiffer/32/208747_2.png) [@cpfiffer](https://discourse.julialang.org/u/cpfiffer)\
**Post date:** [July 11, 2023, 6:33pm UTC](https://discourse.julialang.org/t/what-steps-should-the-julia-community-take-to-bring-julia-to-the-next-level-of-popularity/101389/37 "2023-07-11T18:33:07Z")

</div>

> [@raman\_kumar](#):
>
> 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. 🙏

I’m not sure I agree with this. Academia is good, but it’s not sustainable. Academics usually end up in the real world and face a lot of institutional pressure from whoever employs them next to use more “traditional” tools like R, Python, or Matlab.

One of the big problems I observe with Julia right now is that most of the regular users are academics. These people have lots of free time and the ability to dictate their own tools, but they are also small islands – they don’t manage that many people, and can’t enforce Julia use. Their long-term effect (I think) is probably fairly small.

Something we could be better at is encouraging commercial use. Commercial use is a _massive_ boon for programming languages. People use Python because it works, it covers all the bases, and employers want to pay people who can write Python. Julia doesn’t have the same thing! We use Julia because we love the language and think its a better tool, but few of us are under the impression that someone would pay us for our Julia skills.

I’m not sure how to encourage this. I know Julia Computing has been doing some excellent work to onboard people, but there’s still not many places where I can say “ABC Corp? Oh yeah, I heard they were a Julia shop!”

The more commercial adoption we can push for the better. I have no idea how, but I think that’s a good goal to consider.

An additional goal is **more education and outreach**. At some point the Julia evangelists got quiet and stopped pushing. I include myself as someone who did this. I want to see more good-quality blog posts, more neat projects, more talks, more meetups, etc. Things are not as unified as they once were and I think we could do a little more in representing a vibrant community to the world.

---

<div class="post-metadata">

**Author:** ![cpfiffer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cpfiffer/32/208747_2.png) [@cpfiffer](https://discourse.julialang.org/u/cpfiffer)\
**Post date:** [July 11, 2023, 7:05pm UTC](https://discourse.julialang.org/t/what-steps-should-the-julia-community-take-to-bring-julia-to-the-next-level-of-popularity/101389/38 "2023-07-11T19:05:28Z")

</div>

Also – the Julia Slack has to be retired or for core devs only or something. The fact that we’re having so many discussions in a transient, deleted, and gated network means all our community knowledge building gets thrown in the trash. It’s a _really_ big problem and I think we need to be more thoughtful about where we devote energy to communication.

---

<div class="post-metadata">

**Author:** ![Ininterrompue](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ininterrompue/32/5594_2.png) [@Ininterrompue](https://discourse.julialang.org/u/Ininterrompue)\
**Post date:** [July 11, 2023, 8:24pm UTC](https://discourse.julialang.org/t/what-steps-should-the-julia-community-take-to-bring-julia-to-the-next-level-of-popularity/101389/39 "2023-07-11T20:24:54Z")

</div>

> The more commercial adoption we can push for the better. I have no idea how, but I think that’s a good goal to consider.

Yeah I fully agree. Corporate funding is probably the single most impactful thing that could happen in this direction. I’ve heard pushback on this front before but I refuse to believe that it could be a net negative. (Not that my or their opinions would matter to a company if it decided to pursue this.) Mindshare is really powerful and it would force a lot of devs to actually learn the language with direct application to their business, instead of being like “it’s a cool language but I don’t really know how I can use it, or share my Julia code with others.”

Take ML for example. S4TF failed because Swift had practically no ML community, or any scientific community for that matter. Julia’s in a completely different position, where such efforts, even if abandoned as cavalierly as S4TF, would not be gone to waste. In fact, given the way that the language has been marketed, you’d expect Julia to be especially suited for ML.

On the other hand, there’s an acute shortage of devs in this space while the rest of us are “waiting” for Diffraction and Enzyme to mature. Meanwhile a lot of the grad students doing a lot of the hard work graduate and move on, or the work is only sustained through grant funding. Maintenance becomes a lot harder. It’s unsustainable.

> At some point the Julia evangelists got quiet and stopped pushing. I include myself as someone who did this.

I stopped pushing because I realized I detest being marketed a product I wasn’t looking for. “Looks like Python, runs like C” was something that we pushed for a long time and I honestly believe it did some real damage to how the language (and community) is perceived. Devs everywhere are well-aware of the problems with two languages and if there’s something out there that claims to solve it, they’re going to have some pretty high expectations. Repeatedly comparing with Python and C++ just fueled the antagonism, especially when they figured out that you couldn’t compile to small binaries for anything beyond toy problems. Marketing should be humble and presented in such a way as to not set people up for disappointment.

---

<div class="post-metadata">

**Author:** ![xiaoxi](https://avatars.discourse-cdn.com/v4/letter/x/a9adbd/32.png) [@xiaoxi](https://discourse.julialang.org/u/xiaoxi)\
**Post date:** [July 11, 2023, 8:46pm UTC](https://discourse.julialang.org/t/what-steps-should-the-julia-community-take-to-bring-julia-to-the-next-level-of-popularity/101389/40 "2023-07-11T20:46:16Z")

</div>

> [@cpfiffer](#):
>
> An additional goal is **more education and outreach**.

In anticipation of JuliaCon, would it be possible for each of the big Julia Github orgs to write a blog post reflecting on the last 12 months of development? With a bit of luck, between JuliaCon and the blog posts, July could become Julia month.

[Previous page](https://discourse.julialang.org/t/what-steps-should-the-julia-community-take-to-bring-julia-to-the-next-level-of-popularity/101389.md?page=1)

[Next page](https://discourse.julialang.org/t/what-steps-should-the-julia-community-take-to-bring-julia-to-the-next-level-of-popularity/101389.md?page=3)