Rust in Production: JetBrains

In our Rust in Production interview series, we talk with developers and technical leaders who are shaping how Rust is built and used in practice.

This interview explores JetBrains’ strategy for supporting the Rust Foundation and collaborating around shared tooling like rust-analyzer, the rationale behind launching RustRover, and how user adoption data shapes priorities such as debugging, async Rust workflows, and test tooling (including cargo nextest).

Today’s guest is the Head of the Rust Ecosystem at JetBrains, Vitaly Bragilevsky.

In talks and interviews you often emphasize JetBrains’ long-term commitment to the Rust ecosystem, including your involvement in the Rust Foundation and collaboration around rust-analyzer. How do you balance building proprietary JetBrains tooling with contributing to shared, community-owned Rust infrastructure in a way that actually accelerates Rust adoption rather than fragmenting the tooling landscape?

We think about this balance very deliberately, because the last thing the Rust ecosystem needs is artificial fragmentation driven by vendors pulling in different directions.

First, it’s important to be precise about our role. We don’t directly contribute code to core Rust open-source projects like rust-analyzer, but we very much share the same underlying problems. Because of that, we stay in close communication with the rust-analyzer team, exchange feedback, and align in direction where it makes sense. In parallel, we participate in Rust Foundation programs focused on supporting the people and processes behind Rust development, not on controlling technology.

From a product perspective, our default stance is: use what the Rust ecosystem already provides whenever possible. We rely on the standard Rust toolchain and regularly evaluate which existing components can be reused or integrated into RustRover rather than reinventing them. This helps us stay compatible with how Rust developers already work and lowers the cognitive cost of adopting the language.

Regarding fragmentation, I see it a bit differently. Diversity of tools and approaches isn’t a failure mode by default – it’s often a strength. Different developers, teams, and domains need different workflows. A strictly limited, highly opinionated tooling setup may be elegant, but it can also exclude people. Healthy competition and multiple well-integrated tools give users real choice, and that choice is what ultimately accelerates adoption.

Our goal is not to replace or overshadow community-owned infrastructure, but to build on top of it and around it: providing a polished, integrated experience for users who value that, while staying aligned with the broader ecosystem. When developers can pick the tools that fit them best – whether that’s lightweight editors, full IDEs, or something in between – Rust becomes more accessible, not more fragmented.

RustRover is JetBrains’ first dedicated Rust IDE after years of offering Rust support as plugins for IntelliJ IDEA and CLion. From your perspective as Head of the Rust Ecosystem, what concrete signs inside JetBrains and in the wider community convinced you that the time had come to invest in a standalone Rust product rather than “just” improving the plugins?

The decision was driven by a combination of external signals from the Rust ecosystem and very practical internal considerations at JetBrains.

Externally, we saw sustained, long-term growth of Rust – not just in developer adoption, but in serious production use by companies across very different industries. More teams were betting on Rust for core systems, making the ecosystem commercially relevant in a way that clearly went beyond enthusiasts and early adopters. At that point, simply treating Rust as an add-on to other IDEs no longer reflected how important it had become for many users.

Internally, having a standalone product matters a lot. It allows us to put Rust development on a clear roadmap, dedicate a focused team, and invest in the experience end-to-end rather than competing for attention and resources within a broader product. From an organizational and product-management perspective, this is a much healthier way to build something long-term.

There’s also a signaling effect that I personally consider very important. When JetBrains launches a dedicated, commercial IDE for a language, it sends a strong message to companies: this technology is mature, well-supported, and a safe bet. In that sense, RustRover is not only a response to Rust’s growth – it’s also a way of reinforcing it, giving teams additional confidence that Rust is ready for broader adoption in professional environments.

JetBrains surveys show a steady rise in Rust usage and in the popularity of advanced IDE tooling such as rust-analyzer and IntelliJ Rust. How is this data influencing your internal roadmap: which Rust adoption patterns among your users most directly shape what your team prioritizes in RustRover and related tools?

For us, surveys are not just about measuring popularity — they’re a way to understand how Rust is actually used in practice and where developers are still paying a lot of friction tax.

The most valuable signals for us are things like the industries where Rust is being adopted, the kinds of applications people are building, and the tooling problems they repeatedly run into. These answers have a very direct impact on our roadmap, because they tell us where better tooling can realistically move the needle for adoption and productivity.

A concrete example is debugging. We consistently see that many Rust developers avoid debuggers altogether, not because they don’t need them, but because the existing experience is often unreliable or hard to use. That’s a clear signal for us to invest more heavily in debugger quality and integration, rather than assuming that “Rust developers just don’t debug.”

We also see that a large share of Rust development today is backend work, with heavy use of asynchronous Rust. That has consequences for everything from code insight and diagnostics to debugging and profiling, and it means we need to focus on improving the developer experience specifically for async-heavy scenarios, not just for small libraries or toy examples.

Finally, the surveys show a significant cluster of Rust usage in areas like blockchain — for example, ecosystems such as Solana. For us, this isn’t a niche curiosity; it’s a signal that real teams are building production systems there, and that investing in better support for these workflows can have a tangible impact. In that sense, our roadmap is shaped less by abstract ideas of what Rust could be used for, and more by careful observation of what Rust developers are already doing today — and where better tools can help them do it with less friction.

For someone who uses Zed/Neovim with a rust-analyzer, what difference would you feel with RustRover. Is the proprietary JB engine better than the tools rust provides and what’s the story for a proprietary engine instead of a community-driven analyzer?

If you’re coming from Zed or Neovim with rust-analyzer, the first difference you’ll notice is that RustRover is not “just” code analysis – it’s a full IDE experience that’s available out of the box and designed to work as a coherent system.

RustRover combines Rust code analysis with a lot of other IDE capabilities: a debugger, a profiler, advanced dependency management, collaboration tools, support for web technologies and databases, and AI features ranging from simple model-based interactions to more advanced agent-style workflows. On the debugging side in particular, we use our own forks of LLDB and GDB, tuned specifically for Rust, because upstream debuggers still struggle with many Rust-specific constructs.

I usually try not to frame this as a direct “rust-analyzer vs. JetBrains engine” comparison. Both analyzers cover a broadly similar feature set, and both have rough edges – Rust is a very complex language, and large real-world codebases stress tools in different ways. Depending on project size, architecture, macros, build setup, and many other factors, developers can get noticeably different results from different analyzers.

Our engine has a long history. It started about ten years ago as part of the IntelliJ Rust plugin, well before rust-analyzer existed, and it was built using the traditional JetBrains approach to deep IDE integration. Interestingly, it was originally started by Aleksey Kladov (matklad) – the same person who later initiated rust-analyzer, which is based on very different architectural principles.

Today, we don’t see a strong reason to abandon our own analysis stack. One major advantage is that we’re much closer to the IDE itself: we’re not constrained by the LSP protocol, and we can build UX features that simply aren’t possible when the analyzer is a separate, generic service. That tight integration enables things like richer refactorings, more context-aware navigation, and smoother interactions across debugging, profiling, and code insight.

Finally, I actually think it’s healthy that Rust has two serious analyzers. It means no one can afford to be complacent. The competition pushes both approaches forward – and in the end, Rust developers are the ones who benefit from that constant pressure to improve.

JetBrains actively supports the Rust Foundation. What motivated this decision, and what kind of value does JetBrains expect to get back?

Joining the Rust Foundation was a very natural step for us at the time. As Rust was entering a more mature phase of adoption, the Foundation emerged as a focal point for coordinating long-term, ecosystem-level efforts: supporting core infrastructure, improving the sustainability of key projects, investing in developer education, and providing a neutral space where companies and the community can work together.

For JetBrains, participation in the Rust Foundation gives us a structured and transparent way to engage at that level. We get the opportunity to talk directly with companies that are deeply invested in Rust, to contribute to discussions about priorities and initiatives, and to propose or support programs that improve the overall developer experience. While the Foundation doesn’t dictate technical direction, it plays an important role in aligning efforts around shared problems that no single company can solve alone.

From a practical standpoint, working with an organization like the Rust Foundation is also simply more convenient and scalable for us as a company. We still communicate with individual open-source projects and with members of the Rust community directly, but the Foundation gives us a central forum where those conversations can happen more systematically and with broader impact.

Ultimately, the value we expect to get back is not a specific technical advantage, but a healthier, more sustainable Rust ecosystem. That directly benefits our users – and, by extension, our products – because better infrastructure, better-supported maintainers, and clearer long-term signals make Rust a safer and more attractive choice for teams and companies.

There is a fairly common perception in the community that testing in Rust can feel less flexible and more verbose – especially when it comes to mocks, fixtures, and test infrastructure, which often rely on third-party crates and careful architectural design. Do you agree that this is a real pain point for Rust developers today? How do you see this area evolving, and is improving test ergonomics something that the language team and tooling vendors like JetBrains are actively focusing on?

I think cargo nextest is a great example of how the Rust ecosystem is evolving to address real testing pain points without overloading the language itself. Rust deliberately keeps its built-in testing model minimal and reliable, but that means that questions of scale – performance, isolation, flaky tests, CI ergonomics – are pushed into external tooling. As projects grow, cargo test often becomes a bottleneck, and that’s exactly the space where nextest provides a much more robust and production-ready test execution model.

What’s important is that nextest doesn’t change how tests are written in Rust at all. All the existing approaches – standard #[test], async tests, fixtures and mocks from third-party crates – continue to work as they are. Instead, it focuses on execution, observability, and control, which are some of the biggest sources of friction for teams working with large Rust codebases. In that sense, it complements the existing ecosystem rather than competing with it.

From a tooling perspective, this is exactly where IDEs can add a lot of value. We see strong demand for better test workflows, and that’s why we’re actively working on deeper integration of cargo nextest into RustRover – including running, debugging, and visualizing test results. Our goal is to hide as much of the infrastructural complexity as possible behind a coherent UX, so developers can benefit from powerful tools like nextest without having to constantly think about how all the pieces are wired together.