When Positron appeared as a next-generation data science IDE, some Julia users naturally had a simple question: if it was born with first-class support for R and Python in mind, why not Julia too?
That question showed up in Positron’s issue tracker in June 2024, in a GitHub issue titled Julia language as a native citizen?. The wording was not demanding. It was not asking for a complete IDE overnight. It was simply asking whether Julia support was planned, especially since Positron already inherited enough VS Code machinery to recognize Julia files.
Positron is not just a general-purpose code editor. It has a Variables pane and a Data Explorer, which places it closer to scientific-computing-oriented IDEs such as the MATLAB IDE or Spyder. Its own messaging has also consistently described it as a next-generation data science IDE.
Over time, that issue became one of the gathering points for Julia users interested in Positron. There was also some discussion on Julia Discourse. It was not just an isolated request from one person. It represented a broader hope: that Julia might eventually become a first-class language in an IDE designed around interactive data science workflows.
For a long time, however, that hope remained abstract. The issue stayed open, marked for the future, without a concrete timeline.
Then, in December 2025, something changed.
Wes McKinney opened a pull request in the main Positron repository titled WIP: Add Julia language support. This was not a small cosmetic patch. The PR attempted to build a real Julia integration: runtime discovery, IJulia kernel integration, LanguageServer.jl support, a custom Julia runtime library, Variables pane support, Data Explorer integration, Help pane integration, basic plots support, and hundreds of unit tests.
For Julia users watching from the outside, this was the first moment when Positron’s Julia story seemed to move from “maybe someday” to “someone is actually building it.”
That mattered. Wes was not just a random contributor. He is the creator of pandas, a co-creator of Apache Arrow, and someone deeply involved in Positron and the wider data tooling ecosystem. A Julia PR from him, inside the main Positron repository, carried a particular signal. It suggested that Julia support might become part of Positron’s own architecture, rather than living forever as an outside experiment.
For roughly ten weeks, the PR existed as a concrete object of hope. It accumulated commits, showed visible progress, and even drew a response from an IJulia maintainer. Plotting started working. Positron’s custom communication layer for variables, plots, and the Data Explorer was described as not too difficult to get working. The PR was still clearly experimental, but it was real.
Then, near the end of February 2026, the PR was closed.
That closure changed the shape of the story. Julia support did not disappear, but it moved out of the mainline Positron path. What had looked like a possible official integration became, in practice, an external community extension story.
Soon after, ntluong95 picked up the work and developed Julia for Positron as an extension. That effort deserves credit. It took code that might otherwise have remained stranded in a closed PR and turned it into something users could actually try. Later, the project moved under TidierOrg, and the extension continued to evolve with support for the Julia runtime, LanguageServer.jl, variables, data exploration, plots, packages, testing, debugging, and formatting.
This is impressive work.
But it also raises a central question: what kind of maintenance model should Julia users expect for language infrastructure?
The issue is not whether Julia can technically work inside Positron. The answer is clearly yes. The closed PR showed that deep integration is possible, and the community extension reinforces that point.
The harder question is whether this integration has a sustainable home.
There is a meaningful difference between a feature being possible, a feature being available as a community extension, and a feature being owned as part of an IDE’s long-term language strategy. Julia support in Positron currently seems to sit somewhere between the second and third category. It exists, it is improving, and it is useful. But it does not yet feel like a first-class commitment from Positron itself.
That is the story I wanted to share.
A nearby comparison is Flexible Julia for JetBrains IDEs.
Flexible Julia is not an official Julia project either, and from the outside it may also look like the work of a very small team, perhaps even a single visible developer. But its maintenance model is different. It is distributed as a commercial plugin through the JetBrains Marketplace rather than as a purely volunteer community extension. That does not automatically make it better, nor does it guarantee long-term success. But it does change the sustainability question: there is a product, paying users, and a direct incentive to keep up with JetBrains platform changes.
This is different from a community extension that depends mostly on voluntary maintenance around a fast-moving IDE. In both cases, users still have to judge quality and reliability for themselves. But the organizational shape is not the same.
That distinction is what I find interesting. A language integration can be technically impressive and still leave users uncertain about its future if the ownership model is unclear.