Rust should provide a basic, but solid IDE experience

[aturon]

Overview

For many people—even whole organizations—IDEs are an essential part of the
programming workflow. In the survey, 1 in 4 respondents mentioned requiring IDE
support before using Rust seriously. Tools like Racer and the IntelliJ Rust
plugin have made great progress this year, but compiler integration in its
infancy, which limits the kinds of tools that general IDE plugins can provide.

The problem statement here says "solid, but basic" rather than "world-class" IDE support to set realistic expectations for what we can get done this year. Of course, the precise contours will need to be driven by implementation work, but we can enumerate some basic constraints for such an IDE here:

• It should be reliable: it shouldn't crash, destroy work, or give inaccurate
  results in situations that demand precision (like refactorings).
• It should be responsive: the interface should never hang waiting on the
  compiler or other computation. In places where waiting is required, the
  interface should update as smoothly as possible, while providing
  responsiveness throughout.
• It should provide basic functionality. At a minimum, that's: syntax
  highlighting, basic code navigation (e.g. go-to-definition), code completion,
  build support (with Cargo integration), error integration, and code
  formatting.

Note that while some of this functionality is available in existing IDE/plugin
efforts, a key part of this initiative is to (1) lay the foundation for plugins
based on compiler integration (2) pull together existing tools into a single
service that can integrate with multiple IDEs.

Projects

• Rust Language Service, which provides a server that runs in the background, providing IDEs, editors, and other tools with information about Rust programs.

[Nashenas88]

To add to this, I've been working on the borrow visualizer and updating here periodically. I hope to incorporate at least basic functionality into Rust Language Service this year. The final version would be dependent on the MIR implementation of the borrow checker.

[loganintech]

Would you have any plan to write an official Visual Studio Code extension? There is one already but it doesn't support debugging. It does use racer to help with some stuff like goto line but the editor itself already has that.

I should add, some companies have written extensions before. RedHat wrote an extension that supports reference and tons of other stuff.

[abique]

What about QtCreator support?

[Nashenas88]

@JewsOfHazard, it's already in the works with the Rust Language Service. See https://github.com/jonathandturner/rls_vscode

[KalitaAlexey]

You can try my extension: https://github.com/KalitaAlexey/vscode-rust/
It works with RLS or with racer.

[patlecat]

JetBrains.com is certainly a partner that you should intensify the cooperation with because they put some effort into creating a plugin already.

MSVC could also be interested but they will probably demand a .NET version of Rust -> # Rust
Embarcadero.com could also be interested if there is enough demand.

Those 3 are the main IDE manufacturers nowadays.

[sophiajt]

@patlecat - definitely. In fact, we've already been chatting with jetbrains (iirc, we met with someone from jetbrains at the last RustConf).

MSVC (do you mean Visual Studio?) doesn't need a .NET version of Rust. They have a large plugin ecosystem that we could provide a plugin for. If you mean having first-party support straight from Microsoft, I'm not sure where they would fit us into their stack (cloud? games?), but it is a possible in the future as Rust continues to grow.

I think the hope is that having high-quality plugins for all major editors and IDEs give developers the best set of choices. If vendors of IDEs want to add even better support, the RLS is built to let them leverage, and we'd be happy to work with them if they needed additional functionality.

[azazar]

Shouldn't basic functionality include code documentation lookup?

[GuillaumeGomez]

@azazar: I can only approve with this question.

[sophiajt]

@azazar - documentation lookup is something we're working on for RLS (it may already be working in parts, actually).

[Immortalin]

@aturon this issue should be renamed to Basic but solid editing experience

[aturon]

@Immortalin can you say more? The results from last year's survey that partly led to this roadmap goal were specifically about typical IDE experiences.

[Immortalin]

@aturon the phrasing feels more natural...

[tjkirch]

I believe the suggestion is "basic but solid" rather than "solid but basic", because it sounds more positive, and that it has nothing to do with IDE/editor.

[aturon]

@tjkirch Ah, thanks! Updated.

[yarwelp]

Hello, I found this issue via https://blog.rust-lang.org/2017/09/18/impl-future-for-rust.html via /r/rust on Reddit.

In the discussion on Reddit, people were saying to comment on issues and to ask how one can help.

I've only learned a little bit about Rust but I am using it for a program I am writing.

I tried to find a good IDE for Rust on Linux or FreeBSD but found none.

I would like to help in any way possible how ever small. The amount of time I have is limited though as I both study and have a part-time job.

For Python I found PyCharm good and for C++ with Qt, Qt Creator is a decent IDE.

However I think that there is greater potential for what an IDE could do than what we are seeing.

Perhaps it is not feasible but if it was don't you think it'd be better to have an IDE that is written from scratch with Rust in mind rather than making plugins?

What should a good Rust IDE do beyond the obvious things like completion and showing function signatures?

Most IDEs seem focused on the act of writing code and debugging it, but could we have an IDE that helps us better in planning and exploring ideas? If so, how?

Sorry if this is adding noise rather than being helpful, it's just that I think we could do better.

[neuronsguy]

FWIW I think the "basic but solid IDE" goal is already achieved thanks to Intellij-rust. I live in that environment daily and the IDE is not the bottleneck for coding Rust at this point (for me at least).

So while I think the goals of RLS and choice of several IDEs have merit, they seem like next steps ... this issue as currently phrased seems solved to me.

(Except: intellij-rust could really use debugging support. That seems beyond the realm of "basic" though).

[omarabid]

Is VIM/NeoVim considered an IDE?

[rodya-mirov]

@neuronsguy Actually the intellij-rust situation is the major bottleneck for me, and why I'm not spending as much time getting good at rust as I would like.

I come from a Java background, and the ability to hit foo. and then see a list of possible completions is very important for me. When I get two or three deep into iterator chaining (or use diesel, which is whole other level) I can't even cmd+click the figure out what the type of the object is. Even if I figure it out from reasoning (not a given), I can't necessarily figure out what functions it has associated, as they may not be in the same file, but be in the file associated to a trait I didn't think of.

As my rust fluency grows, I'll be able to "guess" more frequently, but "go to definition" and "see available functions" are the must-have features I need from an IDE (way more than running a debugger) and the tooling just isn't there yet.

[natalie-o-perret]

I bet on Jetbrains for the best solution. VSCode and VS will never bring anything decent in terms of productivity (it's like comparing PyCharm / RubyMine and the support in those 2).

Sure it will take time, but can't wait to see Rust having its own IDE in the Jetbrains suite (the plugin stage really sucks and Python has been like that for a while, it was a long time ago... but it did happen).

Plus I like the cross-platform thing support (at least JavaFX is useful for that sort of things, I became a pretty big user of .NET (Core) on Linux just because of that).

The real issue is probably niche market right now, but who knows?
Maybe we'll see an EAP or something of the sort in a year or so (fingers crossed!).